Agent View ignores remote container context when workspace is opened in ssh dev container
- Dominant language
- Shell
- Stars
- 11.2k
- Forks
- 1.9k
- Avg merge
- 14h 16m
- Merged PRs (30d)
- 6
Description
### Describe the bug
## Description
When a VS Code workspace is opened in a remote SSH dev container, the new Copilot Agent View incorrectly initializes on the host system instead of inside the container, ignoring the remote context that the main Chat interface correctly respects.
## Expected Behavior
- Workspace opened in dev container → Chat works correctly in container
- New Agent View opened → should also run in the same container context
- Both interfaces should respect the remote container environment
## Actual Behavior
- Workspace opened in dev container → Chat works correctly in container
- New Agent View opened → **starts on the host system instead of the container**
- Agent has file system access to the host (e.g., `/Users//...`) instead of container paths
- This creates a context mismatch and prevents proper interaction with container-specific tools/dependencies
## Environment
- OS: macOS (Darwin)
- Workspace: SSH remote dev container
- VS Code: Remote - Containers extension enabled
- Copilot CLI: Latest version
## Impact
- Agent cannot access container-specific dependencies/tools
- Workspace context is fragmented between Chat (container) and Agent (host)
- Potential security/privacy issue: agent operates on host file system when it shouldn't
## Suggested Fix
Agent View should automatically detect and respect the VS Code remote context (dev container, SSH, WSL, etc.) on initialization, matching the behavior of the main Chat interface.
### Affected version
latest
### Steps to reproduce the behavior
1. Open a project in a dev container (e.g., via Remote - Containers extension)
2. Verify Chat interface works correctly in container
3. Open Agent View (or new agent session)
4. Check working directory/system info: `echo $PWD` or equivalent
5. **Observe:** Agent is on host system, not in container
### Expected behavior
- Workspace opened in dev container → Chat works correctly in container
- New Agent View opened → should also run in the same container context
- Both interfaces should respect the remote container environment
### Additional context
_No response_
Contributor guide
Research direction
Start by reproducing the issue with the listed SSH dev container steps, comparing Chat and Agent View initialization and checking the working directory with `echo $PWD`. Trace where Agent View establishes its execution context and compare it with the main Chat interface. Done means Agent View runs in the container and can access its paths, tools, and dependencies rather than the host.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- shell, vscode
- Domain
- cli, devops, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100