[Bug] Webview bootstrap blocks on Service Worker update after the expected controller is ready #8073

Existing issues

• I searched existing issues and PRs for the explicit registration/update wait. I did not find a matching report.

Summary

In this Docker deployment, extension webview initialization blocks on an explicit await registration.update() for 45.83 seconds. The expected webview worker takes control approximately 5 ms after the update starts, but content initialization still waits for the update promise. Codex's 30-second renderer watchdog then expires. A second webview's registration also queues for approximately 45.73 seconds. Project Manager was affected as well.

This is separate from a newer Codex preload loop that also froze the entire editor UI. The preload problem is documented in the separate extension investigation below. Bounding the Service Worker update alone did not fix that UI freeze.

OS/Web Information

• Observed: October 24, 2026.
• LinuxServer Docker image: 4.143.1-ls373; build time 2026-10-24T01:07:31+00:00.
• code-server: 4.143.1, commit 22ddf60dbc52f164cff13620ab515086dd08c90a; Code 1.143.1.
• Previous published image: 4.141.1-ls372.
• Browser used for measurements: Chrome for Testing 154.0.8037.97, Linux, Playwright.
• HTTPS deployment behind nginx, with a root PWA Service Worker.
• Codex openai.chatgpt: currently 26.1021.22027; older 26.1007.21434 was also tested during diagnosis.
• Project Manager: 13.1.1.
• The deployment has UI customizations; their contribution has not been fully isolated.

I have not reproduced the scheduling delay in a clean official image or established a browser-independent regression.

Steps to Reproduce (observed deployment)

1. Start an authenticated browser context with empty Service Worker/cache state.
2. Open code-server and extension webviews such as Codex and Project Manager.
3. Record registration, explicit update, controller changes, and webview performance marks.
4. The editor shell is available in approximately 2–5 seconds, while webview initialization remains before content/workerReady.
5. Codex reports renderer_ready_timeout at approximately 30 seconds.

Blocking logic

Generated file:

lib/vscode/out/vs/workbench/contrib/webview/browser/pre/index.html

Relevant original logic:

navigator.serviceWorker.register(swPath).then(async registration => {
  if (navigator.serviceWorker.controller) {
    registration = await registration.update();
  }
  // Wait for controller changes before resolving workerReady.
});

The initial controller in the measured frame was the root PWA worker, /_static/out/browser/serviceWorker.js. Checking for any controller therefore starts another update while the webview worker is still installing.

The update waits 45.83 seconds. The reason for the browser's long update-job scheduling remains unproven. A second webview's register() waits approximately 45.73 seconds, so bounding only the explicit update does not address all observed queueing.

Representative log:

Webview renderer did not become ready elapsedMs=30002 extensionVersion=26.1021.22027 reason=renderer_ready_timeout receivedWebviewMessage=false role=sidebar stage=renderer timeoutMs=30000

Was this introduced by the latest code-server update?

The operator reports that both the previous and current images open the old Codex, and both fail after Codex is updated. This is the operator's A/B observation, not an independently repeated full-image A/B test.

Source comparisons found:

• await registration.update() is present in VS Code 1.141.0, 1.141.1, and 1.143.1.
• Their src/vs/workbench/contrib/webview/browser/pre/service-worker.js files are byte-identical: SHA-256 83c76adde3ba663433523660289f99111bf00f395ef541d567c060a6f7cc7d8e.
• code-server v4.141.1...v4.143.1 changes to patches/webview.diff are context line-number changes.
• Other webview host changes exist, including mounting/key-event handshake changes; the whole older bootstrap should not be copied onto the newer host.

These findings support an existing shared bootstrap weakness exposed alongside the Codex update, rather than a newly added update() wait in this code-server release. They do not exclude every possible backend regression.

Primary source references:

https://github.com/coder/code-server/compare/v4.141.1...v4.143.1
https://github.com/linuxserver/docker-code-server/releases/tag/4.141.1-ls372
https://github.com/linuxserver/docker-code-server/releases/tag/4.143.1-ls373
https://github.com/microsoft/vscode/blob/1.141.1/src/vs/workbench/contrib/webview/browser/pre/index.html
https://github.com/microsoft/vscode/blob/1.143.1/src/vs/workbench/contrib/webview/browser/pre/index.html
https://github.com/microsoft/vscode/blob/1.143.1/src/vs/workbench/contrib/webview/browser/pre/service-worker.js

Local workaround and proposed direction

The original local code-server-webview-timeout.patch is a diagnostic workaround against this deployment's generated files (the source-level PR is narrower and does not introduce the localStorage setting):

1. Reuse a registration only when its exact scope and complete active script URL match the expected worker.
2. Register normally when no usable matching worker exists.
3. Bound the explicit update wait to 3,000 ms by default, continuing with the matching active worker on timeout or update failure. The browser update job itself is not canceled.
4. Still require the expected worker to control the iframe. Request a narrowly validated clients.claim() when necessary; controller acquisition has a separate 10-second failure timeout.
5. Update the inline CSP hash without relaxing the CSP.

Local setting, in the code-server origin's browser console:

localStorage.setItem('code-server.webview.swUpdateTimeoutMs', '3000');

Reload after changing it. Values from 0 to 60,000 ms are accepted; invalid values default to 3,000. This is a local patch setting, not an upstream option or an environment variable. It bounds only the update wait when a matching active worker exists. It does not limit initial registration or total startup time, and timers need a responsive event loop.

Validation and limits

• The shared bootstrap/worker changes were checked separately for a hanging update, controller acquisition, initial registration, syntax, and CSP consistency.
• The final local deployment also skips Codex's pathological modulepreload insertion and batches unmodified startup assets into a worker-side cache. Those extension-specific mitigations are not included in the focused timeout patch.
• With the combined workaround, cold-browser tests reached the Codex welcome screen in approximately 31–44 seconds. During an actual served-page run, opening the command palette took 256 / 151 / 804 ms, with the longest sampled main-frame evaluation taking 755 ms.
• The combined fix restores UI responsiveness; cold startup is still slow. Successful combined tests do not prove that the Service Worker patch alone fixes all Codex startup problems.
• A final actual served-page run reached the welcome screen at 43,738 ms and an editable composer before the interaction test ended at 53,660 ms. Menu opens took 420 / 157 / 588 ms; the longest main-frame evaluation was 939 ms. No chat request was submitted as part of validation.

Would matching-registration reuse and a bounded update wait be appropriate in this bootstrap? Should this be addressed in code-server or VS Code upstream, and what browser tracing would help identify the long update scheduling delay?

Independent extension preload stall (additional investigation)

This section records a separate bottleneck for triage; the shared-Service-Worker PR does not claim to fix it. The CPU-profile findings and deployed cold-start timings below are from the supplied diagnostic notes. The underlying CPU profile, raw timing traces, full image runtime A/B, and cache-rebuild watcher source were not included in the review bundle.

webview/assets/index-7e47869603c2.js
webview/assets/app-main-765fabf054a6.js
webview/assets/app-initial-13f932cb2f13.js

const links = document.getElementsByTagName('link');
for (const dependency of dependencies) {
  for (let i = links.length - 1; i >= 0; i--) {
    // Check whether this dependency already has a link.
  }
  document.head.appendChild(modulePreloadLink);
}

Checks performed while preparing this report

• Independently fetched VS Code 1.141.0, 1.141.1 and 1.143.1 sources: all contain await registration.update(), and all three webview worker SHA-256 hashes match the value above.
• Independently checked the code-server version comparison: the patches/webview.diff changes are hunk line-number updates. Both LinuxServer release tags exist.
• Added real-Chromium regression coverage against the pinned VS Code source bootstrap and actual Service Worker implementation. This isolates worker lifecycle behavior without depending on extension activation or a compiled workbench.
• The unpatched code-server bootstrap fails the root-controller/hanging-update regression. The proposed source patch passes the browser cases. These checks do not reproduce the original 45.83-second browser scheduling delay or the 20-second extension preload profile.

Remaining template information

• Local diagnostic OS: Linux; distribution and remote CPU architecture were not recorded in the supplied notes.
• Native VS Code: not tested.
• VS Code web (code serve-web): not tested.
• GitHub Codespaces: not tested.
• Accessed over a secure context (HTTPS through nginx).

The deployment-specific asset cache and Node.prototype.appendChild interception have been excluded from the proposed upstream code. They depend on extension internals and deployment paths and require separate design and validation.

Proposed source-level fix

PR #8074 addresses the shared Service Worker bootstrap wait and controller acquisition. It excludes the independent Codex preload suppression and deployment-specific module cache.