Eclipse Theia 1.75 Release: News and Noteworthy

We are happy to announce the Eclipse Theia 1.75 release! The release contains in total 51 merged pull requests. In this article, we will highlight some selected improvements and provide an overview of the latest news around Theia. The highlights include support for Agent Plugins from the AI Registry, a Memory capability for agents, and MCP Apps that render their own UI in the chat.

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.75.

Eclipse Theia 1.75: Selected features and improvements

In the following, we will highlight some selected improvements in the new release. As usual, we cannot mention all 51 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.

Agent Plugins From the AI Registry

1.73 added installation of MCP servers and skills from the Eclipse Foundation AI Registry. 1.75 adds the next artifact type: an Agent Plugin bundles skills and MCP servers into one unit that an organization endorses as a whole.

The format is not a Theia invention. Agent Plugins is an open, vendor-neutral standard, published as version 1.0.0 in August 2026, that defines a portable directory layout for Agent Skills and MCP servers: a plugin.json manifest, a skills/ folder and an mcp.json. Its Technical Steering Committee is staffed by maintainers from Amazon, Cursor, Microsoft, OpenAI and Vercel, with Google joining. Clients including ChatGPT, Codex, Cursor, GitHub Copilot, Kiro and VS Code support it. That is what makes the feature more than another install button: the capability set your team maintains is packaged once and travels between agent clients, instead of being rearranged for each of them. Theia 1.75 implements the v1.0.0 loading contract as a client.

Agent Plugins get their own section in the Extensions view, searchable with @agent-plugins, and each card offers Install, Update, Fix, Link, Unlink and Uninstall. Installing downloads the source, verifies it against the endorsed content hash, and moves it into ~/.agents/plugins/. A hash mismatch raises a dialog. From there, the plugin’s skills are loaded under a qualified name (bigquery-data-analytics:query-builder), and its MCP servers are written into the ai-features.mcp.mcpServers preference with a back-pointer to the plugin. Both are reconciled when the plugin root changes on disk.

Failures stay local: a broken mcp.json disables MCP for that one plugin, a single broken server entry is skipped, and neither affects the plugin’s skills.

Installed artifacts also keep themselves current now (#17887). Theia checks the registry once per window load and either applies an update or offers it, following the ai-features.registry preference. The default is set once in the user scope, and a gear context menu on each skill and MCP server card overrides it per artifact, marking whether the effective mode is inherited or set for that artifact.

One Unified AI Configuration View

Over time, AI configuration in Theia had grown into several places at once: a set of tabs in the AI Configuration widget, plus ai-features.* entries spread across the Settings UI. Finding the one setting you wanted meant knowing which of the two to open.

1.75 consolidates all of it into a single view with flat category navigation: General, Providers & Models, Model Aliases, Agents, Prompts & Skills, Prompt Snippets, Variables, Tools, Token Usage and MCP Servers. AI preferences are now hidden from the Settings UI, and ai-features.* deep links are redirected into the view, so there is one place left to look.

Two things that were previously invisible now have a home. The per-agent reasoning level and the provider server tools introduced in 1.71 and 1.73 are written by the selectors in the chat input, but until now there was no way to see, change or clear them outside a chat session. Both show up in the agent detail page. The new Prompt Snippets category lists the fragments that had no page of their own: your own snippets in .prompts/*.prompttemplate, the agent capability fragments, and the generic capabilities.

Smaller conveniences: the category tree shows item state as a dot, for example for a running MCP server, and offers the category’s add action inline, so creating an agent or a server does not require opening its page first.

How you get there has changed as well: the AI Configuration is no longer available under View → Views or View: Open View. It now opens with Alt+A, from the “Manage” menu behind the gear icon in the bottom left of the application, or directly from the AI Chat view.

For adopters, the view is extensible through the new AiConfigurationCategory contribution point, backed by an AiConfigurationService that reads and writes AI preferences in a workspace-trust-aware way. This is a breaking change: the per-tab configuration widgets and their WidgetFactory registrations are gone, @theia/ai-ide and @theia/ai-mcp now depend on @theia/ai-core-ui, and a custom AI configuration tab has to be re-implemented as an AiConfigurationCategory contribution. The stable entry points (aiConfiguration:open, aiConfiguration:openTools, and the chat toolbar button) are unchanged. See the AI Configuration View section of the Theia Migration Guide for the details.

Some parts are left for follow-ups: the view currently edits the user scope only, and structured settings such as custom Anthropic models still fall back to “Edit in settings.json”.

Agents Notice When Files Change Behind Their Back

An agent that read a file was never told when you, a formatter, or another agent changed it afterwards. It kept reasoning about content that no longer existed, and a whole-file write then overwrote your edit.

1.75 tracks, per session, the content an agent was handed. Before the next request, the agent gets a trailing message listing the files that changed since it read them, repeated until it reads them again. On top of that, writeFileContent and suggestFileContent refuse to overwrite a file that changed since it was read, so the agent has to re-read before it writes. The replacement tools need no guard, since they re-read at write time and fail when the content they matched is gone.

The tracking is in memory and bounded (32 sessions, 200 files each), and changes are reported at turn boundaries, so a change made in the middle of a turn is caught by the write guard but only reported with the next request.

A Memory Capability for Agents

Theia 1.75 adds a built-in “Memory” prompt capability. It lets an agent maintain a wiki-style knowledge base in the workspace, compiling raw session output into short, linked concept articles that later tasks can reuse:

.agents/memory/raw/     # append-only ingest: session logs, verbatim findings
.agents/memory/wiki/    # compiled articles, one concept each, linked from index.md

The location follows the convention already used for skills, and keeping it in the workspace means the content is project-scoped and can be version controlled along with the code it describes. As a prompt capability, it is available to any adopter of Theia AI and can be added to custom agents. In the Theia IDE, it is currently integrated in the Coder agent (“Next” prompt) as an opt-in and is off by default, so the team can field-test it; we plan to integrate it into the default agents once it has proven itself.

Open Editors as Agent Context

What you currently have open says a lot about what you are working on. 1.75 makes that available to agents in two ways: a prompt fragment referencing the existing openEditors variable, enabled by default for the Universal, Architect and Coder agents and removable through prompt customization, and a contribution that adds the open editors to the current context automatically, guarded by a user preference that is on by default.

MCP Apps

An MCP tool call ends in text. That is the right default for most tools, but it makes anything interactive awkward: a trace, a chart, a sortable table or a form with more than two fields has to be flattened into prose, and the user is left describing in words what a click would have expressed. Hosts that wanted more than that had to build a custom renderer per server, which does not scale and defeats the point of having a protocol.

MCP Apps is the standardized answer. Like Agent Plugins above, it is not a Theia invention: it is an extension to the Model Context Protocol, grown out of the community mcp-ui project and the experience of OpenAI’s Apps SDK, that lets a server ship the view along with the tool. The server registers its UI as an ordinary MCP resource under a ui:// URI, and a tool declares which of those templates its result should be rendered with. The host fetches the resource, renders it in a sandboxed iframe, and gives it a JSON-RPC channel back over postMessage, so a click inside the widget can call the server’s tools and receive the results. The host stays in the middle: the iframe does not talk to the server directly, and the templates are declared up front instead of arriving with a result, so a host can tell what it is about to render.

Theia 1.75 implements the host side of this. An MCP server’s app renders inside the AI chat in a sandboxed iframe rather than as a plain text result. So far it has been tried with the TMLL trace server MCP, a natural fit: trace visualization is exactly the kind of output that does not survive being turned into prose. In the screenshot below, TMLL runs its anomaly detection against a Trace Compass trace server and plots what it found right in the chat, instead of describing the outliers in numbers.

More Theia AI Improvements

Better slash command parsing: A /word in the chat input is only treated as a command if it actually resolves to a command or prompt fragment. Sentences like please look at /home/user/notes.txt and fix the bug, or a pasted stack trace containing a path, now reach the model unchanged instead of being cut off and turned into a chip.

Google model defaults: gemini-3.7-flash is added to the Google default model list, and the default and fast aliases point at it. The Anthropic and OpenAI defaults were already current.

Fixes: Skill directories configured in the preferences are picked up on startup instead of only after a change (#17929). The chat’s suggest widget opens upwards, so it is no longer hidden behind the bottom panel (#17890), restoring a large session by double-click no longer leaves two active sessions (#17916), and streaming a long answer after a tool call no longer leaks one listener per token (#17883). The Anthropic provider now drops thinking blocks that cannot be replayed, which previously made every retry of a conversation fail with a 400 and stalled agent tool loops (#17905).

The Theia IDE as an Eclipse Enclave Tool

Just before this release, we shipped Eclipse Enclave, an open source sandbox that runs AI coding agents in isolated containers behind a network allowlist. It is not a 1.75 change, but it is closely tied to Theia: two of its tools are theia and theia-next, so an agent session can run inside the Theia IDE rather than a terminal harness. enclave --tool theia starts the container and opens the IDE already attached to it, building on the --attach-container option from 1.72. Theia AI’s requests then leave through the Enclave gateway, and tool confirmations are off by default: keeping the agent contained is the sandbox’s job, not the IDE’s.

Running several sandboxed IDE sessions in parallel is not possible yet. We are working on that on the Theia side and expect it with 1.76.

The Source Control Graph Catches Up With VS Code

The SCM history graph introduced in earlier releases was still missing most of its toolbar and a good part of its visual language. 1.75 works through the open items of #17457 and closes that gap.

Visually, the graph now mirrors VS Code’s color map (#17880): the current, remote and base refs color their commit row, their ref badge and the first-parent chain below them, while the remaining lanes rotate through scmGraph.foreground1-5, so a diverged local and remote branch stay distinguishable. The HEAD indicator follows the current ref’s revision instead of guessing the first row on lane 0, which marked the wrong commit whenever the remote was ahead, and hovers are rendered from what the history provider sends: with vscode.git, that is the same hover as its blame decoration, including author, dates, change stats and actions such as “Open Commit” or “Open on GitHub”. One caveat for adopters: the default lane colors change for providers that do not supply current-ref information.

The toolbar catches up as well. VS Code’s ref filter picker, a multi-select quick pick over the provider’s branches, remote branches and tags, drives which history items are requested and how they are colored, and arrives together with a refresh action and preferences under scm.graph (#17881). Pull and Push work now, after failing with “no active handlers available for the command” because vscode.git gates them on a context key Theia never set (#17876). And “Go to Current History Item” scrolls to the commit the current ref points at, paging further history in if needed, while “View as List” and “View as Tree” switch how the changes of an expanded commit are laid out (#17923).

With the graph in place, @theia/scm-extra is deprecated (#17882). Its SCM History view is covered by the graph for branch history and by the Timeline view for per-file history, and it has been non-functional in the default application since @theia/git was removed, since nothing implements ScmHistorySupport anymore. The package is no longer published on npm, is removed from the example applications, and all its exported APIs are marked @deprecated since 1.75.0.

Walkthroughs on the Welcome Page

Theia now implements the VS Code contributes.walkthroughs contribution point, so extensions can ship guided walkthroughs. The Welcome page lists the pending ones as cards with a progress indicator, and opening one lets it take over the view, with the tab named after the walkthrough. Steps are ticked off from the step icon or completed in bulk with “Mark Done”, and progress survives a reload.

Steps also complete themselves through the usual VS Code events: onCommand, onContext, onSettingChanged, extensionInstalled, onView and onLink. Walkthroughs and steps whose when clause does not hold are hidden, and hidden steps stay out of the progress, so a walkthrough that only partly applies can still be completed. The commands walkthrough.open, workbench.action.openWalkthrough and walkthrough.resetProgress offer a picker when no walkthrough is given, and VS Code’s workbench.welcomePage.walkthroughs.openOnInstall preference is registered as well.

There is nothing to install to try this: the bundled ms-python.python and ms-toolsai.jupyter builtins already contribute walkthroughs, and the Help menu has an “Open Walkthrough” entry (#17958).

Base Technology Updates

Node.js 26, Node.js 22 dropped: Theia follows the Node.js LTS cadence. Node 26 joins the build and test matrix, Node 22 support ends, and engines.node is now >=24. Node 24 stays the recommended default and is what the lint, release and publishing workflows use, because Node 26 only becomes Active LTS at the end of October 2026.

Electron 42.8.1: The desktop stack moves from 42.3.0 to 42.8.1. Electron 42.4.0 replaced extract-zip with a Rust-based implementation, which removes the postinstall race that caused sporadic ENOENT failures on Node 24, so the yauzl override that pinned it is dropped again.

VS Code API 1.134.0: API compatibility moves up from 1.130.0, which unblocks extensions targeting that version. There were no public vscode.d.ts changes in between, so no adaptations were needed on the Theia side.

React 19 only: As announced with the peer support added in 1.73, React 18 is dropped: react and react-dom are ^19 only on @theia/core. All Theia packages now compile with React’s automatic JSX runtime (jsx: react-jsx), so JSX files no longer need React in scope. New @theia/core/shared/react/jsx-runtime and jsx-dev-runtime re-exports make sure the generated JSX calls resolve to the single shared React instance.

Webpack bundling removed: esbuild has been the default bundler since 1.72 for applications without a webpack.config.js, and theia build now always uses it. The generated webpack configurations, NativeWebpackPlugin, MonacoWebpackPlugin and the webpack dependency tree are gone, replaced by nativeDependenciesPlugin, monacoNlsPlugin and exposeModulePlugin. Applications that still carry a webpack.config.js need to migrate to esbuild.

Startup Performance

Three changes take work off the cold start path. The skill scan no longer blocks frontend contributions from starting (#17843), backend, headless and frontend plugins are deployed concurrently instead of one after another (#17867), and the preferences widget with its four child widgets is only constructed when you actually open Settings (#17877).

The first two were measured on a developer machine: the skill scan accounted for around 3.6 seconds of blocking work in the frontend startup path and now stays below the threshold at which Theia warns about a slow contribution, and the time the frontend spends waiting for plugin deployment dropped from roughly 520 to between 150 and 270 milliseconds. Both are measurements of a single startup phase rather than end-to-end startup times, and cold start timings vary a lot between runs, so what you see depends on your machine and workspace. The third change avoids work rather than making a measurable difference: constructing the preferences widget never took long enough to show up in a startup trace in the first place.

Additional Improvements

Beyond that, 1.75 brings a number of smaller fixes and improvements across the platform:

• Themes and workbench: the tree search box is visible again, after third-party base styles that load after Theia’s own had won on equal specificity since 1.72 (#17873), light color themes without their own editor theme no longer render inverted, because the fallback follows the theme’s declared type instead of always using the dark default (#17864), toolbar areas are no longer draggable or text-selectable (#17940), and the layout is saved again when a Chrome tab closes, since the deprecated unload event was replaced with pagehide (#17870). Restoring persisted perspective layouts at startup no longer logs a tree error on every start, and a stale refresh no longer re-inserts a removed subtree (#17886).
• Secondary windows: a Monaco editor in a secondary window is styled again, so the AI chat input has a visible cursor, selection and suggest widget there, SelectComponent dropdowns render in the window that owns them, and the platform font class is applied (#17874). Those fixes come with a small breaking change, as MonacoFrontendApplicationContribution loses its protected secondaryWindowHandler field. The Terminal Manager can be moved to a secondary window when terminal.grouping.mode is tree, with its close confirmation dialog opening there instead of invisibly in the main window (#17945). Quick inputs, such as the file variable picker, still open in the main window.
• Editors and plugins: VS Code’s editor group navigation commands are implemented, which makes bindings such as the Vim extension’s ctrl+w h/j/k/l work (#17742), and webview calls for an already disposed webview are no-ops instead of unhandled promise rejections in the plugin host (#17956).
• Deployment and tooling: a browser-only build can prepare its plugins at build time through the new @theia/plugin-utils package (#17758), theia download:plugins no longer hard-exits and aborts the process on Windows (#17896), and a stale connection token behind a caching reverse proxy is recovered by forcing a full response instead of a 304 (#17762).
• Housekeeping: the migration from console to the injected ILogger continues across the AI and task packages (#17763) and is now enforced by a custom ESLint rule that also checks the @named logger naming convention (#17687), and a dependency update brings the known advisories down from 2 critical and 12 high to 1 critical and no high ones (#17909).

For a complete overview of all changes in this release, please refer to the 1.75 milestone. All these features and improvements (in total 51) 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