Dev Containers 0.459.1 / VS Code 1.123.0: attached-container reconnect still intermittently fails with "Reconnect attempt without old result"

Summary

This issue appears to still happen with VS Code 1.123.0 + Dev Containers 0.459.1, despite a maintainer comment in #11601 saying it appeared resolved with that version combination.

The important difference is that my failure is on the attached-container authority path, not the dev-container authority path from #11601.

In my case:

• Reload With Extensions Disabled almost never fails.

• Normal Developer: Reload Window almost always fails.

• Starting from a fresh Dev Containers: Attach to Running Container sometimes succeeds and sometimes fails.

• The first resolveAuthority(attached-container,1) can succeed.

• After local extensions start activating, the extension host is terminated normally.

• The second resolveAuthority(attached-container,2) then fails with:

  • no resolver for attached-container
  • Reconnect attempt without old result

This looks like an attached-container reconnect race or lifecycle issue that is triggered or amplified by normal extension activation order.

Environment

Version: 1.123.0 (user setup)
Commit: 6a44c352bd24569c417e530095901b649960f9f8
Date: 2026-06-03T11:29:03+02:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.19045

Dev Containers extension:

ms-vscode-remote.remote-containers@0.459.1

Remote mode:

Dev Containers: Attach to Running Container
Remote authority: attached-container
Docker context: non-default Docker context

Other Remote-related extensions installed:

ms-vscode-remote.remote-containers@0.459.1
ms-vscode-remote.remote-ssh@0.124.0
ms-vscode-remote.remote-ssh-edit@0.87.0
ms-vscode-remote.remote-wsl@0.104.3
ms-vscode-remote.vscode-remote-extensionpack@0.26.0
ms-vscode.remote-explorer@0.5.0
ms-vscode.remote-server@1.5.3

Some extensions that are active around the failure window in the logs:

formulahendry.auto-close-tag@0.5.15
formulahendry.auto-rename-tag@0.1.10
wayou.vscode-todo-highlight@1.0.5
vscodevim.vim@1.32.4
usernamehw.errorlens@3.28.0
PKief.material-icon-theme@5.35.0
ms-vscode-remote.remote-wsl@0.104.3

Relationship to #11601

#11601 was closed after a comment saying this appeared resolved with:

VS Code 1.123.0 + Dev Containers 0.459.1

However, I can still reproduce a very similar failure with the same VS Code and Dev Containers versions.

The difference is:

#11601: resolveAuthority(dev-container,2)
My case: resolveAuthority(attached-container,2)

So this may be a related but distinct bug in the attached-container reconnect path.

Observed behavior

Normal reload often fails to reconnect to an already running attached container.

The failure pattern is:

1. VS Code activates ms-vscode-remote.remote-containers for attached-container.
2. PendingMigrationError: navigator is now a global in nodejs is logged from the Dev Containers extension.
3. First resolveAuthority(attached-container,1) succeeds.
4. VS Code returns a local endpoint, for example 127.0.0.1:<port>.
5. Other local extensions start activating.
6. The extension host receives a terminate message from renderer and exits with code 0.
7. VS Code starts a new extension host.
8. The second resolveAuthority(attached-container,2) fails because there is initially no resolver for attached-container.
9. After ms-vscode-remote.remote-containers activates again, final resolve fails with Reconnect attempt without old result.

Relevant log excerpt

2026-06-09 21:30:51.933 [info] ExtensionService#_doActivateExtension ms-vscode-remote.remote-containers, startup: false, activationEvent: 'onResolveRemoteAuthority:attached-container'

2026-06-09 21:30:52.098 [error] PendingMigrationError: navigator is now a global in nodejs, please see https://aka.ms/vscode-extensions/navigator for additional info on this error.
    at get (.../extensionHostProcess.js:833:7243)
    at it (...\.vscode\extensions\ms-vscode-remote.remote-containers-0.459.1\dist\extension\extension.js:20:5257)
    ...

2026-06-09 21:30:52.144 [info] [resolveAuthority(attached-container,1)][0ms] activating remote resolvers attached-container+...
2026-06-09 21:30:52.144 [info] [resolveAuthority(attached-container,1)][0ms] invoking final resolve()...
2026-06-09 21:30:57.939 [info] [resolveAuthority(attached-container,1)][5795ms] setting tunnel factory...
2026-06-09 21:30:57.939 [info] [resolveAuthority(attached-container,1)][5795ms] returned 127.0.0.1:40045

2026-06-09 21:31:00.115 [info] ExtensionService#_doActivateExtension formulahendry.auto-close-tag, startup: true, activationEvent: '*'
2026-06-09 21:31:00.117 [info] ExtensionService#_doActivateExtension formulahendry.auto-rename-tag, startup: true, activationEvent: '*'
2026-06-09 21:31:00.139 [info] ExtensionService#_doActivateExtension wayou.vscode-todo-highlight, startup: true, activationEvent: '*'
2026-06-09 21:31:00.473 [info] ExtensionService#_doActivateExtension ms-vscode-remote.remote-wsl, startup: false, activationEvent: 'onStartupFinished'

2026-06-09 21:31:00.581 [info] Extension host terminating: received terminate message from renderer
2026-06-09 21:31:00.581 [info] ExtensionService#_doActivateExtension usernamehw.errorlens, startup: false, activationEvent: 'onStartupFinished'
2026-06-09 21:31:00.581 [info] Extension host with pid 44316 exiting with code 0
2026-06-09 21:31:00.634 [info] Extension host terminating: received terminate message from renderer
2026-06-09 21:31:00.645 [info] Extension host with pid 27100 exiting with code 0

2026-06-09 21:31:01.157 [info] Extension host with pid 13588 started
2026-06-09 21:31:01.157 [info] [resolveAuthority(attached-container,2)][0ms] activating remote resolvers attached-container+...
2026-06-09 21:31:01.164 [error] [resolveAuthority(attached-container,2)][11ms] no resolver for attached-container undefined

2026-06-09 21:31:01.181 [info] Extension host with pid 12608 started
2026-06-09 21:31:01.209 [info] ExtensionService#_doActivateExtension ms-vscode-remote.remote-containers, startup: false, activationEvent: 'onResolveRemoteAuthority:attached-container'
2026-06-09 21:31:01.404 [info] [resolveAuthority(attached-container,2)][226ms] invoking final resolve()...
2026-06-09 21:31:01.404 [error] [resolveAuthority(attached-container,2)][226ms] returned an error Reconnect attempt without old result.

Steps to reproduce

I do not yet have a fully minimized extension set, but the issue is consistently correlated with normal extension activation.

Current observed repro:

1. Open VS Code 1.123.0 with Dev Containers 0.459.1.
2. Use Dev Containers: Attach to Running Container.
3. Attach to an already running container using the attached-container authority.
4. Wait until the window is fully loaded.
5. Run Developer: Reload Window.
6. Observe that reconnect often fails with Cannot reconnect / Reconnect attempt without old result.

Control case:

1. Run Developer: Reload With Extensions Disabled.
2. Attach/reload the same running container.
3. Reconnect almost never fails.

Additional observation:

• Directly attaching without reload is intermittent.
• Normal reload with extensions enabled almost always fails.
• Reload with extensions disabled is much more stable.

Expected behavior

Reloading the VS Code window should reconnect to the already running attached container.

If the old resolve result is unavailable after extension host restart, the attached-container resolver should either recover by performing a fresh attach or fail with a more actionable diagnostic. It should not get permanently stuck in Reconnect attempt without old result while the container is still running.

Actual behavior

VS Code fails to reconnect even though the container is still running.

The second resolveAuthority(attached-container,2) fails with:

no resolver for attached-container
Reconnect attempt without old result.

Why I think this is still a bug in 1.123.0 + 0.459.1

I understand #11601 was reported as resolved with VS Code 1.123.0 + Dev Containers 0.459.1. However, this issue still reproduces in that exact version combination in the attached-container path.

The fact that Reload With Extensions Disabled almost never fails suggests that normal extension activation timing can trigger or amplify the race. But the failure still occurs in the Dev Containers remote authority resolution path, and the attached container remains running.

The resolver appears to lose or require an old resolve result across extension host restart, then cannot recover.

Request

Could you please check whether the fix/verification for #11601 covered only the dev-container authority path?

It would be useful to know whether attached-container reconnect is expected to support recovery after local extension host restart, especially when the first resolve already succeeded and returned a local endpoint.