github eclipse-che/che 7.123.0
Eclipse Che 7.123.0

7 hours ago

Enhancements

Eclipse Che can now be deployed on OpenShift for IBM Z (s390x) and ARM

Eclipse Che on OpenShift previously deployed on linux/amd64 only. The oauth-proxy sidecar of the che-gateway pod was pinned to quay.io/openshift/origin-oauth-proxy:4.22, which is published with a single linux/amd64 manifest — on any other architecture the gateway stalled at 3/4 containers with ImagePullBackOff, even though every other Che component already shipped multi-arch images.

The Che Operator now resolves the oauth-proxy image dynamically at CheCluster reconciliation time from the cluster's own openshift/oauth-proxy ImageStream. Managed by the Cluster Version Operator, this ImageStream always carries an architecture-native, digest-pinned image from the cluster's release payload, so the right image is selected on whichever architecture the cluster runs — with no per-architecture configuration. The operator uses the internal registry reference (status.dockerImageRepository@digest), so the image also pulls in disconnected clusters. When the ImageStream is unavailable, the operator falls back to the RELATED_IMAGE_gateway_authentication_sidecar default, preserving existing behavior on Kubernetes and other non-OpenShift environments.

DevWorkspace Operator 1.0.0

DevWorkspace Operator 1.0.0 is included in this release. For the full list of changes, see the DevWorkspace Operator 1.0.0 changelog.

Change the editor of an existing workspace without recreating it

To change the editor of an existing workspace without recreating it, the Overview tab of Workspace Details now has an Editor row with a pencil button that opens a Change Editor modal, following the same pattern as Change AI Tools. The modal lists every available editor, with an inline version picker for editors that ship multiple versions. Previously, switching a workspace to a different IDE meant pushing your work to Git and creating a second workspace with another editor selected, leaving duplicates behind.

Screenshot 2026-10-05 at 17 24 51

Manage Git provider OAuth tokens from the Git Services tab

You can now manage Git provider OAuth tokens from the Git Services tab, separate from the credentials you added yourself. Tokens generated through a Git provider OAuth flow are now shown and managed on the Git Services tab, next to the provider that issued them. To make it clear which credentials you configured yourself and which were issued automatically, OAuth tokens are no longer mixed in with your own credentials on the Personal Access Tokens tab of the User Dashboard.

The Git Services tab gains:

  • A Token Name column showing the name of the Kubernetes Secret that holds the OAuth token for each provider.
  • A Delete OAuth Token row action, enabled once a token exists. It removes the stored Secret without revoking the authorization on the provider side, and asks for confirmation before deleting.

The Personal Access Tokens tab now lists only the personal access tokens you added yourself.

Screenshot 2026-10-02 at 14 40 16

Keep working with Git after your OAuth token expires

To keep working with Git after your OAuth token expires, Che now stores the OAuth refresh token and expiration time in the same Kubernetes Secret as the access token, so short-lived provider tokens — GitLab's expire after two hours — are renewed automatically instead of forcing a workspace restart. Credentials also survive a che-server restart, since they are restored from the persisted Secrets. A new POST /oauth/refresh endpoint lets you trigger a refresh for a given provider.

Visual Studio Code (Desktop) (SSH) no longer requires key management

Connecting to a developer workspace configured with the "Visual Studio Code (Desktop) (SSH)" editor required public key authentication. This requirement has been removed to simplify the workflow and remove the need to manage keys.

Open the project root as the workspace when no projects are detected

To open the project root as the workspace when no projects are detected, add the option "workspace.openProjectsRootOnEmpty": true to the vscode-editor-configurations configmap. Previously, when starting a workspace with no projects configured, Che Code would launch with an empty explorer (no workspace).

Update look & feel of JetBrains IntelliJ Gateway landing page

In addition to updating the look & feel of the JetBrains Gateway landing page, the workflow of connecting directly from an IntelliJ editor is now also mentioned.

image

Bug fixes

Use OpenShift group names that contain spaces in advanced authorization

Previously, Che Server inserted the raw name into the OpenShift Groups API path, producing an invalid URI and failing with java.net.URISyntaxException when an affected user opened the dashboard. You can now use OpenShift group names that contain spaces — common for Active Directory–synced groups such as TEAM GROUP — correctly in allowGroups and denyGroups. Group names are now percent-encoded as URL path segments before the lookup, so members of an allowed group reach the dashboard and non-members remain denied.

spec:
  networking:
    auth:
      advancedAuthorization:
        allowGroups:
          - "TEAM GROUP"

Sample cards no longer disappear from the dashboard when the internal registry is disabled

Setting disableInternalRegistry: true incorrectly gated the custom getting-started-samples ConfigMap source as well, leaving the Get Started page empty for users who supplied their own samples. The dashboard now always fetches custom ConfigMap samples and only hides the built-in airgap samples when disableInternalRegistry is true.

Create a second workspace from the same Git URL

The "Create New" switch on the Import from Git flow was silently reset to OFF as soon as a valid repository URL was entered, so starting a second workspace from the same URL redirected to the existing one instead of creating a new one. The switch now retains its state, allowing you to create multiple separate workspaces from the same GitHub or GitLab URL.

Prefer a personal access token over OAuth for Git operations

When both a personal access token (PAT) and an OAuth token existed for the same SCM provider, the most recently created secret was used, so a freshly minted OAuth token could shadow a user-configured PAT. Because OAuth tokens can be short-lived (for example, GitLab OAuth tokens expire after 2 hours), Che now always prefers the PAT and preserves it during OAuth token refresh, avoiding unexpected authentication failures.

Read validation error messages in dark mode

Error helper text in the Gitconfig tab of User Preferences used an icon-tier danger color that failed the WCAG 2.2 AA minimum contrast ratio (3.38:1) in dark mode. The text now uses PatternFly's text-specific danger token, which remaps to a lighter shade in dark mode and achieves 5.56:1 contrast; light mode is unaffected.

Technology Preview

Keep extensions in the internal OpenVSX registry up to date automatically

To keep extensions in the internal OpenVSX registry up to date automatically, you can now enable an operator-managed CronJob that periodically compares installed extensions against open-vsx.org and publishes newer stable versions automatically. Configure it under spec.components.openVSXRegistry.extensionAutoUpdate in the CheCluster CR (docs). Previously, extensions in the internal OpenVSX registry were published once and never refreshed, so they drifted out of date compared to their upstream versions on open-vsx.org and required manual re-publishing.

Screenshot 2026-09-23 at 12 33 59

Don't miss a new che release

NewReleases is sending notifications on new releases.