CommandCodeAI / CommandCodeAI/command-code
WebSocket connections fail behind Fence sandbox (ignore HTTPS_PROXY)
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 4k
- Forks
- 350
- PR merge metrics
- No merged PRs in 30d
Description
Summary
When running Command Code inside popular sandbox tool Fence (https://github.com/fencesandbox/fence) (Linux sandbox using bwrap --unshare-net), all WebSocket connections time out. Fence routes network traffic through an HTTP proxy (HTTPS_PROXY=http://127.0.0.1:3128) since direct TCP is blocked by the network namespace.
curl, fetch, and HTTP requests work correctly. However, new WebSocket(url) (used in buildSandboxStreamUrl / defaultCreateSandboxStreamSocket) ignores proxy env vars and attempts a direct TCP connection, which is blocked by the sandbox.
The codebase already has detectProxyFromEnv(). Maybe use ws package with https-proxy-agent for WebSocket connections when a proxy is detected, instead of the built-in WebSocket
Expected Behavior
CommandCode working inside Fence sandboxing
Actual Behavior
Connection issues with Fence. Can't use CommandCode with it.
Steps to reproduce the issue
- Install and configure Fence ( https://github.com/fencesandbox/fence )
- Run CommandCode with "fence cmd"
Command Code Version
1.10.0
Operating System
Linux
Terminal/IDE
JetBrains-JediTerm
Shell
bwrap
Session file (optional)
No response
Fix prompt (optional)
No response
Additional context
No response
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing buildSandboxStreamUrl and defaultCreateSandboxStreamSocket, then inspect how detectProxyFromEnv is used for existing HTTP requests. Reproduce the Fence sandbox failure and verify that WebSocket connections succeed through the configured HTTPS_PROXY without breaking direct connections.
Written by the indexing model from the issue text.
Assessment
- Domain
- cli, networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100