Copilot Chat terminal tools fail with ENOPRO after reconnect in code-server web session on iPad

[clia]

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: Safari, Chrome
• Local OS: iPadOS 26.5
• Remote OS: Debian Linux 13
• Remote Architecture: X64
• code-server --version: 4.118.0

Steps to Reproduce

I cannot provide a 100% minimal reproduction yet, but the failure pattern is consistent:

1. Connect to a remote code-server instance from an iPad browser.
2. Open a remote workspace.
3. Use GitHub Copilot Chat in agent mode and trigger a terminal tool action such as run_in_terminal.
4. The first command works normally.
   Example: cargo test
5. During the same overall session, the remote connection / extension host is interrupted and later restored.
6. Try another Copilot terminal tool action such as:
   • run_in_terminal
   • terminal_last_command
   • terminal_selection
7. The tool now fails with ENOPRO and references file:///... instead of vscode-remote://....

Expected

After reconnecting or recovering the extension host in code-server web mode, Copilot Chat terminal tools should continue to use the remote workspace context and should either:

• rebind to the restored terminal instance correctly, or
• create a new valid remote terminal session

They should not fall back to a file:// URI for a workspace that is still remote / web-backed.

Actual

When using code-server from an iPad browser session, GitHub Copilot Chat terminal tools can work initially, but after a reconnect / extension host recovery event they start failing with:

ENOPRO: No file system provider found for resource 'file:///home/dev/github.com/snow-ui-rs/snow-ui'

At the same time, terminal-related tools may also report:

No active terminal instance found.

The important detail is that the same workspace previously worked in the same chat session using a remote URI like:

vscode-remote://<authority>/home/dev/github.com/snow-ui-rs/snow-ui

but later the terminal tool path appears to be treated as:

file:///home/dev/github.com/snow-ui-rs/snow-ui

This looks like a post-reconnect state/restore issue in web mode, where terminal/tool session recovery loses the remote workspace binding and falls back to file://.

Logs

I found evidence consistent with terminal/session recovery problems:

- remote extension host reconnection occurred
- terminal recovery logged an old terminal id mapping to `new id undefined`
- Copilot terminal tools later could not find an active terminal instance
- the failing tool invocation used `file://` instead of the earlier `vscode-remote://`

Examples from local logs/session records:

- Copilot Chat session record showed an earlier successful terminal run with remote cwd
- later tool invocations failed with `ENOPRO`
- pty host log showed terminal recovery anomalies around reconnect time

Screenshot/Video

No response

Does this bug reproduce in native VS Code?

No, this works as expected in native VS Code

Does this bug reproduce in VS Code web?

This cannot be tested in VS Code web

Does this bug reproduce in GitHub Codespaces?

This cannot be tested in GitHub Codespaces

Are you accessing code-server over a secure context?

• I am using a secure context.

Notes

What I Observed

Before the failure:

• terminal tool execution succeeded
• workspace/cwd was recorded as vscode-remote://...
• command completed successfully

After reconnect/recovery:

• terminal-related tools reported No active terminal instance found
• subsequent run_in_terminal failed with:
  ENOPRO: No file system provider found for resource 'file:///home/dev/github.com/snow-ui-rs/snow-ui'

Why This Seems Related To code-server Web Mode

This does not look like a project-specific issue.

Reasons:

• the project itself is accessible through normal file tools
• commands had already succeeded earlier in the same session
• the failure appears only after reconnect/recovery behavior
• the URI scheme changes from vscode-remote://... to file://...
• this happens in a browser-based code-server session from iPad, which suggests web-mode state/session restoration may be involved

Relevant Logs / Signals

I found evidence consistent with terminal/session recovery problems:

• remote extension host reconnection occurred
• terminal recovery logged an old terminal id mapping to new id undefined
• Copilot terminal tools later could not find an active terminal instance
• the failing tool invocation used file:// instead of the earlier vscode-remote://

Examples from local logs/session records:

• Copilot Chat session record showed an earlier successful terminal run with remote cwd
• later tool invocations failed with ENOPRO
• pty host log showed terminal recovery anomalies around reconnect time

Environment

• code-server accessed from iPad browser
• remote Linux server
• GitHub Copilot Chat extension: 0.46.0
• VS Code core version reported by the environment: 1.118.0

If needed, I can provide sanitized log excerpts and a more detailed reconnect timeline.

Additional Notes

My current suspicion is one of these:

1. terminal restore after reconnect does not correctly re-adopt the tool session
2. restored terminal state loses the remote workspace/provider binding
3. web-mode state recovery causes terminal/chat tooling to reconstruct the cwd/resource as file:// instead of vscode-remote://

If this should be filed upstream in VS Code instead, I would appreciate guidance on the best component/owner.

[smerschjohann]

this is an upstream bug: microsoft/vscode#311229 microsoft/vscode#301804

It is the missing/restricted Filesystem API in Safari.

[clia]

Thanks!