Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
remoteEnv variables defined in devcontainer.json are only injected into the remote server environment during the initial container creation. On every subsequent reconnection (window reload, Cursor restart, or connecting to an existing container), only SSH_AUTH_SOCK is set — all other remoteEnv variables are silently dropped.
devcontainer.json (relevant section)
“remoteEnv”: {
“PATH”: “${containerEnv:PATH}:${containerWorkspaceFolder}/bin”,
“LOCAL_WORKSPACE_FOLDER”: “${localWorkspaceFolder}”,
“LOCAL_HOME_FOLDER”: “${localEnv:HOME}”,
“DIRENV_VENV”: “false”,
“TESTCONTAINERS_HOST_OVERRIDE”: “host.docker.internal”
}
Evidence from extension logs
Initial container creation (all variables set correctly)
2026-03-28 10:16:05.470 [info] Setting remote env LOCAL_WORKSPACE_FOLDER
2026-03-28 10:16:05.470 [info] Setting remote env LOCAL_HOME_FOLDER
2026-03-28 10:16:05.470 [info] Setting remote env PATH
2026-03-28 10:16:05.470 [info] Setting remote env DIRENV_VENV
2026-03-28 10:16:05.470 [info] Setting remote env TESTCONTAINERS_HOST_OVERRIDE
2026-03-28 10:16:05.470 [info] Setting remote env AWS_SSO_LOGIN
2026-03-28 10:16:05.470 [info] Setting remote env SSH_AUTH_SOCK
The run-user-commands CLI invocation correctly includes --remote-env flags for all variables:
Spawned process 85137: … ‘run-user-commands’ … ‘–remote-env’ ‘LOCAL_WORKSPACE_FOLDER=/Users/me/Workspace/project’ ‘–remote-env’ ‘LOCAL_HOME_FOLDER=/Users/me’ ‘–remote-env’ ‘PATH=/home/vscode/.nvm/versions/node/v20.12.2/bin:…:/workspaces/lumos/bin’ ‘–remote-env’ ‘DIRENV_VENV=false’ ‘–remote-env’ ‘TESTCONTAINERS_HOST_OVERRIDE=host.docker.internal’ ‘–remote-env’ ‘SSH_AUTH_SOCK=/tmp/cursor-remote-ssh-…sock’
Every subsequent reconnection (only SSH_AUTH_SOCK set)
2026-03-28 10:47:29.843 [info] Setting remote env SSH_AUTH_SOCK
2026-03-28 10:47:29.843 [info] Returning resolved authority
This pattern repeats identically for every reconnection throughout the day (10:55, 10:57, 11:53, 12:27, 12:28, 12:43, 13:38, 13:44, 13:51, 14:10, 14:14, 14:21, 16:23, and all sessions after).
Verification inside the container
The cursor-server process (/proc//environ) contains zero remoteEnv variables. The container’s Docker label devcontainer.metadata correctly stores the resolved remoteEnv values, confirming the config was parsed — it’s just not applied on reconnection.
$ echo $DIRENV_VENV
(empty)
$ echo $TESTCONTAINERS_HOST_OVERRIDE
(empty)
$ echo $PATH | grep -c ‘/workspaces/lumos/bin’
0
Root cause (from log analysis)
The extension has two code paths for connecting to a container:
Initial creation (Configuring devcontainer… → run-user-commands with --remote-env flags): All remoteEnv variables are resolved and passed correctly.
Reconnection (Returning resolved authority path): Only SSH_AUTH_SOCK is injected. The code does not re-read remoteEnv from the devcontainer config or container metadata label.
The second path is triggered when the extension finds an existing container (via docker inspect) and starts/reuses it rather than creating a new one. Since most developer sessions involve reconnecting to an existing container (e.g., after Cursor restarts, window reloads, or laptop sleep/wake), remoteEnv effectively never works in practice.
Expected behavior
All remoteEnv variables should be injected on every connection to the container, not just during initial creation. The resolved values are already available in the devcontainer.metadata Docker label, so the reconnection path should read and apply them.
Context
The forum post from July 2025 indicated remoteEnv support was added in v1.0.9. The initial-creation path does work, suggesting the feature was implemented for that flow but not for the reconnection flow.
Steps to Reproduce
- Install anysphere devcontainer extension
- Open folder in devcontainer (remoteEnv is set)
- Rebuild devcontainer (remoteEnv no longer set)
Expected Behavior
remoteEnv variables are always set
Operating System
MacOS
Version Information
Version: 2.6.22
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0
Does this stop you from using Cursor
Yes - Cursor is unusable