Eclipse Theia 1.72 Release: News and Noteworthy

June 15, 2026 | 16 min Read

We are happy to announce the Eclipse Theia 1.72 release! The release contains in total 67 merged pull requests. In this article, we will highlight some selected improvements and provide an overview of the latest news around Theia.

For those new to Eclipse Theia, it is the next-generation platform for building IDEs and tools for the web or desktop, based on modern state-of-the-art web technologies. With Theia AI, part of the Theia platform, you can also build AI-powered tools and IDEs with ease. For more details about Eclipse Theia, please refer to this article and visit the Theia website.

The Theia project also releases a product, the Theia IDE. The Eclipse Theia IDE is a modern, AI-native, and open IDE for cloud and desktop environments, aimed at end users. The Theia IDE is based on the Theia platform and also includes advanced AI powered features. For more details, see the Theia IDE website.

If you are looking for a simple way to check out the new release, please download and install the Theia IDE, which is based on Theia 1.72.

Eclipse Theia 1.72: Selected features and improvements

In the following, we will highlight some selected improvements in the new release. As usual, we cannot mention all 67 improvements, however we will focus on the most notable changes as well as changes visible to end users. The corresponding pull requests are linked under the respective heading when applicable.

esbuild as the New Default Bundler

Theia 1.72 ships a long-awaited change for adopters: esbuild is now supported as an alternative bundler to webpack for browser, browser-only, and Electron applications. In our measurements, this reduces full build time from roughly 20 seconds to about 2 seconds, a tenfold improvement. Watch-mode rebuilds benefit accordingly.

Technically, the existing webpack-based generator has been renamed to a more generic bundler-generator that now also emits three esbuild build contexts (browser, node, electron), invoked from the CLI. CSS handling was adjusted to fit esbuild’s expectations: ~-based imports of other CSS files are moved into code, @import statements are pulled to the top of files, and the resulting bundle.css is consumed via index.html rather than being inlined into the JS bundle.

Webpack support is still available and remains the default for existing applications. The new bundler is opt-in for now, but we plan to make it the default in a future release and may eventually deprecate the webpack path to reduce maintenance overhead. Two follow-up areas to be aware of: esbuild does not currently emit compressed artifacts or support code splitting/chunking. For most Theia applications the trade-off is well worth it.

To make the new path usable in practice, two related fixes ship in the same release: yargs 17 is now called as a factory in the generated esbuild template, so CLI flags like --mode and --watch are actually parsed, and a parse fix in gen-esbuild.browser.mjs ensures source maps and minify flags are honored. With those in place, esbuild source maps are rewritten to absolute file:// URLs so Chrome and Node debuggers actually bind breakpoints to TypeScript sources out of the box, without custom webRoot or sourceMapPathOverrides configuration.


Side-by-side build of the Theia IDE browser application: esbuild in 2.95s vs. webpack in 92.56s (webpack segment shown sped up)

Multi-Root Workspace Support for AI Agents

AI agents in Theia can now properly operate across multi-root workspaces. Previously, file access, task lookup, launch configurations, and command execution were effectively scoped to the first workspace root. With 1.72, agents see and address all roots equally, using a clear <rootName>/<relativePath> path convention.

Key changes for users and adopters:

  • A new WorkspaceRootsVariableContribution injects workspace root information into every agent system prompt, so the LLM knows which roots exist and how to address them.
  • Tasks, launch configurations, and debug sessions disambiguate by an explicit workspaceRoot parameter when names collide across roots.
  • The shell execution tool now requires a cwd argument and resolves it on the frontend, so commands are always rooted in a known directory.
  • The directory structure, GitHub repository variable, skills, search provider, and editor context variable iterate all roots and produce root-prefixed paths.
  • Per-root .gitignore handling.

This is a breaking change for adopters that extended the previous single-root assumptions: FileValidationState.INVALID_SECONDARY, WorkspaceFunctionScope.getWorkspaceRoot(), and WorkspaceFunctionScope.isInPrimaryWorkspace() are removed. resolveRelativePath() is now synchronous. A few agents (Codex agent, Claude Code command/slash-command contributions) still operate against the first root only and are marked with TODOs for follow-up.

A New “Fast” Model Alias for Simpler Agents

Not every agent task needs a heavyweight reasoning model. Theia 1.72 introduces a new default/fast model alias targeting cheaper and faster models for exploration, basic tool calling, and other short, narrow tasks. The defaults are Claude Haiku 4.5, GPT-5.4 mini, and Gemini 3 Flash.

The Explore, GitHub, Project Info, Command, and Chat Session Naming agents now default to default/fast. These agents are tool-call heavy or perform short tasks where deep reasoning adds latency without adding value. The result is noticeably snappier behavior for the agents users interact with most often, while Coder, Architect, and similar agents continue to use the regular default alias.

Safer Default for Tool Confirmation

The previous * magic key inside ai-features.chat.toolConfirmation has been replaced with a dedicated ai-features.chat.defaultToolConfirmation preference. It is now a regular setting visible in the standard Settings UI, and its default has changed from always_allow to confirm. New tools that an agent uses will ask for confirmation unless the user explicitly opts in to auto-allow them.

Tools that explicitly opt into confirmAlwaysAllow (i.e., tools that should always confirm regardless of the global default, like shellExecute) keep that behavior. Per-tool preference entries still win over the default. The change is intentionally a slight shift toward caution: the safer default catches new MCP servers or newly added skills before they run unattended.

External Paths Allow-list for Read-only AI Tools

AI tools in Theia are workspace-scoped by default. Theia 1.72 adds a new ai-features.workspaceFunctions.allowedExternalPaths preference that lets users opt-in to read-only access for specific paths outside the workspace, for instance to share a documentation folder or a generated artifact tree with the agent.

The allow-list is empty by default, so existing behavior is preserved. When set, the read-only tools getFileContent, getWorkspaceFileList, getWorkspaceDirectoryStructure, and findFilesByPattern accept paths under the allow-listed directories. getFileDiagnostics and all write tools (writeFileContent, suggestFileContent) remain strictly workspace-scoped. The check uses path-component matching (not raw string prefix) and rejects .. traversal, so a sibling path like /external/configs-other/ is not implicitly trusted when /external/configs/ is allow-listed. The workspace trust integration from #17364 extends to the new preference: workspace-scoped overrides are dropped when the workspace is not trusted.

Terminal Command AI Variable

Building on top of the terminal command history added in 1.70, Theia 1.72 introduces a new #terminalCommand AI variable. It lets users target a specific command and its output from the last used terminal directly in a chat request, either by index or interactively via the arguments picker. Without an index, the variable defaults to the last executed command. If the experimental command history is disabled, the variable falls back to the last 50 lines of the terminal buffer.

This is the first user-facing piece built on the terminal command tracking infrastructure introduced in 1.70 and makes it easy to ask an agent things like “explain why the previous command failed” or “summarize this build output” without manually copy-pasting.


Inserting the `#terminalCommand` variable via the arguments picker, then having the agent access and execute the selected command and discuss its output.

Context-Aware Token Usage Indicator

The chat token usage indicator no longer scales to a hardcoded 200k context window. It now reflects the actual maxInputTokens of the active agent’s primary model, fetched from each provider where possible:

  • Anthropic: model metadata is fetched from /v1/models, replacing the static per-model token map and the regex-based reasoning detection in the frontend. Also covers max_tokens, reasoning capabilities, and xhigh effort.
  • Google: fetched from /v1beta/models. The effort vs. budget API shape still uses a model-id heuristic since Gemini’s API does not expose it.
  • OpenAI: a single openai-model-defaults.ts table covers context window, reasoning, dev-message role, structured output and streaming, consolidating four previously separate arrays and regexes.

Each manager now exposes a single resolveMetadata entry point. The visible result is a much more meaningful progress bar in the chat input area: 80% on a 200k-context model is very different from 80% on a 1M-context one, and the UI now shows the right thing.

Theia AI Improvements

Theia 1.72 also brings several quality-of-life improvements to the AI experience:

Show description and arguments in tool confirmation: Generic tool confirmation dialogs previously only showed the tool name, leaving users to guess what createPullRequest was about to do. The dialog now displays the tool’s description and a collapsible <details> block with a one-line preview of the arguments, expanding to the full formatted arguments rendered through the same markdown pipeline used by the args hover tooltip. For tools like GitHub MCP’s create-pull-request, key fields like title, body, and target repo are now visible at the moment of decision.

Tool confirmation dialog in the chat view, now showing the tool description alongside the tool name and a collapsible arguments preview

Keyboard shortcuts and batch allow for tool confirmation: Approving or denying tool calls via the tool confirmation dialog now supports keyboard shortcuts for the Allow and Deny actions, making it much faster to keep an AI session moving when you are reviewing a series of tool calls. The same PR also adds a preference to batch-allow default tools so you do not have to confirm each one individually.

The Tools view in the AI Configuration view allows the user to batch-allow all default tools, so first time users don't need to confirm each individual tool call

Improved provider error presentation: Provider errors (invalid API keys, rate limits, etc.) used to surface as escaped JSON blobs. They now render as a clean Error <code>: <message> line with a collapsible “Details” block, both in the chat output and in the session card tooltip. Notifications use the same formatted headline instead of raw JSON. Includes nested handling for providers like Gemini that pack JSON inside JSON.

Better chat session cards: Session cards now show the pinned agent’s icon and name (@coder · 2 hours ago), display Running and Error status badges in tooltips, and persist hasError and pinnedAgentId in ChatSessionMetadata so the indicators are correct even on cold sessions after a reload.

Tool registry stays in sync with MCP servers: Removing an MCP server from preferences now properly cleans up its frontend tool registrations and prompt fragments. Selected tool IDs are preserved in user preferences so they automatically reactivate when the server comes back, but stale ~{toolId} placeholders no longer leak into agent system prompts.

Robust restore for interrupted tool calls: Reloading a chat in the middle of a long-running tool call (e.g. a multi-second shell command) used to produce an unresolved tool_use entry that providers like the OpenAI Response API rejected with 400 Missing required parameter. The deserializer now synthesizes a stand-in result, so the conversation can continue and the call is rendered as interrupted.

Mode model alternation fix for strict templates: A Theia AI turn with text plus tool calls used to translate to consecutive assistant messages, which strict Jinja chat templates (e.g. llama.cpp serving Devstral or Mistral-Small) rejected outright. They are now squashed into a single assistant message carrying both content and tool_calls, restoring compatibility with these self-hosted setups.

OpenAI Responses API token usage fix: Token usage across internal tool-call round-trips was accumulating into an inflated cumulative prompt total. Usage is now emitted per iteration, so the chat indicator reflects the latest request context rather than the sum of all previous ones.

AI white-labeling: Continues the work to make Theia-based products easier to brand. References to “Theia” / “Theia IDE” in command and PR-review prompt templates, the Copilot auth dialog, the Capability tree functions description, the chat welcome screen, the Getting Started AI banner, agent-completed window-blink titles, and several agent descriptions now use the {{productName}} placeholder. See #17442 for the remaining items, which mostly need a small backend equivalent of productName or moving preference schemas out of common/.

Devcontainer: Attach to Running Container from CLI

Theia 1.72 introduces --attach-container <id|name> to start Theia already connected to a running container, plus --no-dev-json to skip devcontainer config scanning. Short container ID prefixes are accepted. This is useful for scripted workflows where the container is started ahead of time and Theia is launched against it directly.

In the same change set, the attach flow added in 1.71 receives a number of refinements:

  • A trust warning dialog before any container interaction.
  • Multi-source workspace path candidates from devcontainer metadata labels, the devcontainer.local_folder label, WorkingDir, and bind mounts, deduplicated, with a custom-path option.
  • Scanning for devcontainer.json inside the container via Docker exec, controlled by a new devcontainer.attach.applyFoundConfig preference (always / ask / never).
  • shutdownAction: 'none' so containers are not stopped on disconnect.
  • A new RemoteAutoShutdownService that exits the remote backend after 5 minutes of idle (configurable via --remote-auto-shutdown-timeout), so unused remote backends do not keep running indefinitely.
  • Shell-injection hardening in the Docker CLI path: exec/execSync replaced with execFile/execFileSync, with argument escaping for the container-side sh -c paths.

The change is a breaking change for adopters that integrate against the remote container provider: attachToContainer now takes an AttachContainerOptions object instead of a plain containerId string, and RemoteConnection.copy() parameter is narrowed to string.

Support for ESM VS Code Extensions

VS Code extensions delivered as ESM modules (.mjs, or .js with "type": "module") previously failed to activate in Theia with errors like Cannot find package 'vscode' imported from plugins/vscode.github/extension/dist/extension.js. Theia 1.72 implements proper ESM support: ESM plugins are loaded via dynamic import(), and a Node ESM loader hook (embedded as a data: URL so it survives webpack and esbuild bundling) maps import 'vscode' to a per-importer synthetic CJS module. Static exports.<name> = __api.<name> lines are emitted so cjs-module-lexer can expose named ESM imports such as import { commands, window } from 'vscode'.

As a direct consequence, the built-in vscode.github and vscode.github-authentication extensions are no longer excluded by default. Two sample plugins (plugin-esm and plugin-esm-mjs) were added under sample-plugins/sample-namespace/ for adopters who want a reference.

VS Code Compatibility

VS Code API and built-in extensions: VS Code API compatibility has been upgraded to version 1.121.0. There are no public API changes in vscode.d.ts between 1.116.1 and 1.121.0, so no theia.d.ts updates were required this cycle. The bump unblocks extensions targeting 1.121.0, and the nls.metadata has been refreshed accordingly.

Honor when clauses on view containers: VS Code’s contributes.viewsContainers entries support a when clause for conditional visibility. Theia previously dropped this field, so extensions that guarded their containers behind mutually exclusive context keys ended up with all of them visible, leading to empty panels and duplicate menu entries. The scanner now reads the when field, and PluginViewRegistry filters the toggle menu action and the Open View quick pick on it. The change also fixes the visible “duplicate sidebars” issue reported with Anthropic’s Claude Code extension.

Auto-derive defaults for plugin configuration properties: Aligns Theia with VS Code’s behavior of auto-deriving a type-based default for plugin-contributed configuration properties that declare a type but no default ('' for string, false for boolean, 0 for number/integer, [] for array, {} for object, null otherwise). Plugins that relied on this VS Code semantics, like the Vue (Official) extension, no longer hit a Configuration key "vue.server.path" is not defined error and on-hover documentation works as expected. The change is scoped to plugin-contributed configurations only, so Theia’s own preferences and the Settings UI are untouched.

Editor and Workbench

Workspace trust follow-ups and interactive hover tooltip links: The “under development” caveat in the trust dialog has been replaced with concrete descriptions of what trusting/not trusting a workspace means. The dialog is split into three sections (trust implications, restricted mode explanation, “Learn more” link to the docs page), the restricted mode tooltip lists the specific disabled features (tasks, debugging, extensions, AI) and links to docs and the manage command. In the same change, markdown links in core hover tooltips become interactive: anchor clicks are routed through OpenerService so command: URIs invoke CommandOpenHandler and http(s)/mailto/etc. open via their respective handlers. MarkdownString.isTrusted is honored.

Improve navigation support in the merge editor: A round of fixes to navigation between conflicts in the merge editor, addressing the issues collected in #17241.

Small UI fixes:

Disabled extensions stay visible as installed: A regression from #16513 caused disabled extensions whose installed version was not available on the configured Open VSX registry (e.g. installed from VSIX) to show as uninstalled after a window reload, leaving no way to re-enable or uninstall them from the UI. The Extensions view now shows them with a Disabled badge and the proper Enable / Uninstall actions.

macOS Polish

Two long-standing macOS rough edges are smoothed out in 1.72:

Allow Ctrl+Click to open the context menu in the editor gutter: On macOS one-button mice, the standard Ctrl+Click gesture is the canonical way to open a context menu. In the editor gutter this used to add a breakpoint instead. Platform-independent context-menu event recognition replaces the old platform-specific gesture handling, and a Ctrl+Click no longer also creates a breakpoint.

Omit + separator from menu shortcuts on macOS: Keybinding accelerators with macOS modifier symbols now render as ⌃⌘V instead of ⌃+⌘+V, matching the platform convention and removing confusing shortcuts like ⌘++ for magnification. Electron’s native menus and non-macOS platforms keep their existing rendering.

Additional Improvements

The 1.72 release also includes several less visible but valuable changes:

Unbind root services at backend shutdown: The BackendApplication now unbinds all services in the root container at shutdown with a 5-second timeout. This lets @preDestroy hooks and other deactivation handlers run, so singleton backend services can finally clean up external resources they allocated. The onStop() call-backs are now invoked in parallel, which is worth noting for any adopter that depended on a particular ordering.

For a complete overview of all changes in this release, please refer to the 1.72 milestone. All these features and improvements (in total 67) were the result of one month of intensive development. Eclipse Theia follows a monthly release schedule. We are looking forward to the next release due next month, stay tuned! To be notified about future releases, follow us on LinkedIn or follow Theia on Twitter and subscribe to our mailing list.

If you are interested in building custom tools or IDEs based on Eclipse Theia, EclipseSource provides consulting and implementation services for Eclipse Theia, for AI-powered tools, as well as for web-based tools in general.

Furthermore, if you want to extend Theia, Theia AI or the Theia IDE with new features or strategically invest into the project, EclipseSource provides sponsored development for Theia, too. Finally, we provide consulting and support for hosting web-based tools in the cloud.

👉 Get in contact with us, to discuss your use case!

👉 Subscribe to our YouTube channel

Stay Updated with Our Latest Articles

Want to ensure you get notifications for all our new blog posts? Follow us on LinkedIn and turn on notifications:

  1. Go to the EclipseSource LinkedIn page and click "Follow"
  2. Click the bell icon in the top right corner of our page
  3. Select "All posts" instead of the default setting
Follow EclipseSource on LinkedIn

Jonas, Maximilian & Philip

Jonas Helming, Maximilian Koegel and Philip Langer co-lead EclipseSource, specializing in consulting and engineering innovative, customized tools and IDEs, with a strong …