Webview messages from a remote extension stall after the first round-trip — openai.chatgpt (Codex) SPA never finishes bootstrap

[nikolai-vysotskyi]

Summary

When hosting a webview-heavy extension as a remote extension (ExtensionHostKind.Remote + getRemoteAgentServiceOverride({ scanRemoteExtensions: true }) + a real VS Code server), the extension's webview SPA loads fully but stalls mid-bootstrap: the first webview↔extension round-trip succeeds, then no further messages flow, so the SPA never reaches its "ready" state. The same .vsix works perfectly in stock VS Code, so the extension itself is fine.

Concrete case: OpenAI's openai.chatgpt (Codex) extension.

Environment

• @codingame/monaco-vscode-api 33.0.9
• VS Code server pinned to commit 987c9597516278c9fcf10d963a0592ce1384ab93
• Remote extension host (REH server) on localhost:<port>, remoteAuthority set
• Electron 41, macOS (arm64), React 19 renderer
• Service overrides: configuration, extensions, files, model, theme, view-common, views, storage, secret-storage, authentication, notifications, dialogs, chat, extension-gallery, remote-agent

Repro

1. Install openai.chatgpt (platform darwin-arm64) into the REH server's extensions dir; enable its proposed APIs (chatSessionsProvider, languageModelProxy) via product.json.
2. Boot monaco-vscode-api as a remote client to the server; open Codex's custom editor (chatgpt.conversationEditor, scheme openai-codex:) or its webview view.

Expected

SPA boots and renders the chat UI (it does in stock VS Code — verified: renders "Ask Codex to do anything… Powered by your ChatGPT account" in a fresh profile with shared ~/.codex auth).

Actual

• SPA bundle loads fully (all ~250 assets HTTP 200), renders its startup loader.
• Over the webview port I observe the capnp bootstrap:

  webview → ["push",["pipeline",0,["services"]]]
  webview → ["pull",1]
  ext     → ["resolve",1,{customAvatars:{…}, fileAttachments:{…}}]
  

• After that resolve: silence. No further webview↔ext messages (no app-server progress, no shared-object subscribe, no app-level ready). The SPA's ready is gated behind a React <Suspense> that never releases, so the extension's onDidReceiveMessage('ready') init (font/prompts/route) never fires → permanent loader.

Hypothesis

Webview↔extension message delivery for remote extensions appears to stall after the initial exchange — the first capnp round-trip is delivered, but subsequent webview.postMessage / onDidReceiveMessage traffic doesn't flow (possibly ordering/buffering/volume in the remote webview channel, given ~250 concurrent resource loads + capnp). The same SPA over a local ext host (stock VS Code / Cursor) works.

Questions

• Is bidirectional webview↔ext messaging fully supported for remote extensions in monaco-vscode-api, or is there a known limitation/gap?
• Could the concurrent resource-loading + message volume cause drops on the remote webview channel?
• Any guidance to make a webview-SPA extension complete its bootstrap when hosted remotely?

I can provide the full captured message trace and more details. Thanks!

[CGNonofr]

I'm indeed able to reproduces some issues with the codex extension. On my side, the WHOLE browser tab hang, not only the webview, and there are a lot of service worker errors 🤔

That being said, I'm able to reproduce the exact same issue on the last version of code-server

Surprisingly, with the last web-host release of vscodium, the issue seems to be more similar to what you have: the webview never loads but the page stays responsive.

So I guess the issue comes from VSCode itself and not that library 🤔

[nikolai-vysotskyi]

Update after deeper investigation — there are two distinct bugs here, and the first one is squarely in this library

Setup: same openai.chatgpt (Codex) and anthropic.claude-code extensions hosted as remote extensions on a real VS Code server (commit 987c9597…), rendered via renderXxxPart into our own islands. monaco-vscode-api 33.0.9, Electron 41, macOS.

---

Bug 1 — ViewsRegistry.addViews throws because there is no default view container (this library; fixable)

When the workbench processes contributes.views, the handler does (deminified):

const l = this.getViewContainer(a);            // may be undefined for an unknown container id
const d = l || this.getDefaultViewContainer(); // getDefaultViewContainer() => viewContainersRegistry.get("workbench.view.explorer")
…
const m = … d.extensionId …                    // TypeError when d is undefined

getDefaultViewContainer() is this.viewContainersRegistry.get("workbench.view.explorer"), but the views-service-override never registers a default Explorer container, so it returns undefined. Any extension contributing a view into a container that isn’t present in the build (ms-vscode.js-debug → debug, Codex → agentSessions, …) hits that undefined and throws an uncaught:

TypeError: Cannot read properties of undefined (reading 'extensionId')
    at ViewsRegistry.addViews (Array.forEach)
    at …_handleExtensionPoint
    at …_resolveAndProcessExtensions
    at …_initialize

Because it’s uncaught it aborts the entire contributes.views pass, so every extension’s sidebar views silently fail to register (Claude’s chat-sessions sidebar, Codex’s view container, etc.). This is almost certainly the “its sidebar webview-view does not register under monaco” gap people work around by rebuilding sidebars by hand.

Workaround that fixed it for us (must run before initialize()):

import { viewContainerRegistry, ViewContainerLocation, ViewPaneContainer }
  from '@codingame/monaco-vscode-views-service-override';
import { SyncDescriptor } from '@codingame/monaco-vscode-api/services';

if (!viewContainerRegistry.get('workbench.view.explorer')) {
  viewContainerRegistry.registerViewContainer(
    {
      id: 'workbench.view.explorer',
      title: { value: 'Explorer', original: 'Explorer' },
      ctorDescriptor: new SyncDescriptor(ViewPaneContainer, [
        'workbench.view.explorer',
        { mergeViewWithContainerWhenSingleView: true },
      ]),
      hideIfEmpty: true,
    },
    ViewContainerLocation.Sidebar,
    { isDefault: true },
  );
}

After this the extensionId crash is gone (0 occurrences) and contributed views register normally (workbench.view.extension.codexViewContainer, claudeVSCodeSidebar.open, chatgpt.sidebarView.open, …).

Suggested fix in the library: either register a default Explorer view container in the views override, or null-guard d in addViews so a missing default container degrades gracefully instead of throwing and aborting the whole pass. Is registering Explorer ourselves the intended approach, or should the override own it?

---

Bug 2 — the original webview stall, now better isolated

With Bug 1 worked around, Codex’s UI now reaches its loading screen — both via its sidebar view and via its editor panel (chatgpt.newCodexPanel) — and then stalls exactly as first reported: the capnweb bootstrap does push services → pull → resolve 1, then silence; it never reaches ready.

New datapoint that narrows it: anthropic.claude-code, also a remote extension with a webview, works fully on the identical setup (its editor webview renders and functions). The difference is that Codex’s entire UI is an SPA driving a high-frequency bidirectional capnweb RPC ({type:"vscode-capn-rpc-message"}) over the webview↔extension channel, while Claude uses simple request/response. So this isn’t generic remote-webview breakage — it’s specifically sustained bidirectional webview↔remote-ext message delivery stalling after the first round-trip. (The editor-panel path stalls identically to the sidebar-view path, which rules out the view-hosting layer.)

You noted you reproduced this on stock code-server and VSCodium-web (the VSCodium-web symptom matching ours). Since those repackage VS Code’s web workbench, that points Bug 2 at VS Code core rather than this library. Two questions:

1. Does that match your read — should Bug 2 be filed upstream at microsoft/vscode, and do you have a minimal repro you’d be willing to share / co-file? (The extension is proprietary, so a clean public repro is the main blocker for us.)
2. Is there any monaco-vscode-api-side knob for the remote-webview message channel (buffering / ordering / transferables) worth trying before going upstream?

Happy to provide the full captured webview message trace. Thanks!

[nikolai-vysotskyi]

Filed Bug 2 (the webview-bootstrap stall) upstream at microsoft/vscode, since it reproduces on stock code-server and VSCodium-web: microsoft/vscode#319896. Bug 1 (the missing default view container / addViews null-deref) remains specific to this library — the question above still stands: should the views override register a default workbench.view.explorer container, or should addViews null-guard the default-container fallback?

[CGNonofr]

Bug 1:

Adding complex extensions in partial VSCode setup is always risky, that's not the only problem with it, but if you're able to create a simple-enough workaround PR, I'll have a look at it

Does that match your read — should Bug 2 be filed upstream at microsoft/vscode, and do you have a minimal repro you’d be willing to share / co-file? (The extension is proprietary, so a clean public repro is the main blocker for us.)

Yes. Repro is pretty simple: download VSCodium web extension host, run it, go to the given url, install codex (which is present in openvsx as well), open the codex view 💥

Is there any monaco-vscode-api-side knob for the remote-webview message channel (buffering / ordering / transferables) worth trying before going upstream?

I don't think so. It's a direct websocket connection. The channel can be replaced by something else (like engine.io or sockjs) but it wouldn't help. Apart from not, I'm not aware of any "knob" 🤔

[nikolai-vysotskyi]

Opened #805 with the simple workaround (register a hidden default Sidebar workbench.view.explorer container in the views override only if none exists). If you'd rather guard it at the source, I can switch it to a defensive null-check in viewsExtensionPoint.addViews instead — let me know which you prefer.

[CGNonofr]

If you'd rather guard it at the source, I can switch it to a defensive null-check in viewsExtensionPoint.addViews instead — let me know which you prefer.

It would probably be a bit simpler and less hacky 🤔