bug: Agent process environment leaks stale $SHELL into sessions after chsh in startup script

从 agent/agentssh/agentssh.go 中的 CommandEnv 开始，然后阅读 agent/agent.go 中的 updateCommandEnv，以确认继承的环境条目和显式解析的环境条目是如何排序和去重的。让新会话优先使用刚从 /etc/passwd 读取的 shell，然后验证 SSH、Web 终端和重新连接的 PTY 会话在 chsh 后会公开更新后的 $SHELL。

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

On first workspace boot, the Coder agent process starts before the startup script runs. At that point, /etc/passwd has the default shell (/bin/bash), and the agent process inherits SHELL=/bin/bash in its own environment.

The startup script then runs chsh -s /usr/bin/zsh, which correctly updates /etc/passwd. However, the agent process's own environment (os.Environ()) still contains SHELL=/bin/bash for the lifetime of the process.

When any session is created (SSH, web terminal, reconnecting PTY), CommandEnv() in agent/agentssh/agentssh.go:

1. Calls ei.Shell(username) → reads /etc/passwd fresh → returns /usr/bin/zsh ✓
2. Calls ei.Environ() → returns os.Environ() from agent process → contains SHELL=/bin/bash ✗

The env array is built with os.Environ() first (containing SHELL=/bin/bash), then SHELL=/usr/bin/zsh is appended from the fresh passwd read. This array is passed to updateCommandEnv() in agent/agent.go, which uses first-wins dedup:

for _, env := range current {
    parts := strings.SplitN(env, "=", 2)
    if len(parts) != 2 {
        continue
    }
    if _, ok := envs[parts[0]]; !ok {
        envs[parts[0]] = parts[1]
    }
}

The stale SHELL=/bin/bash from os.Environ() is encountered first and inserted into the map. The correct SHELL=/usr/bin/zsh appended later is silently dropped because the key already exists.

The shell binary used to run the session command is correct (it comes from the shell return value of CommandEnv(), which uses the fresh /etc/passwd read). But the $SHELL environment variable visible inside the session is stale.

Expected Behavior

After chsh changes the login shell in /etc/passwd, all new sessions created by the agent should have $SHELL reflecting the updated value.

The freshly-read shell from /etc/passwd should take precedence over the agent process's inherited $SHELL. Possible fixes:

1. In CommandEnv(), filter SHELL out of ei.Environ() before appending the fresh value — since the fresh value is explicitly resolved from /etc/passwd, the process-inherited value should never compete with it.
2. Append ei.Environ() after the explicit SHELL= entry so the first-wins logic picks the correct value.
3. Have updateCommandEnv() use explicit-wins semantics for variables that are intentionally set by CommandEnv().

Steps to Reproduce

1. Create a workspace template with a startup script that runs:

   apt-get install -y zsh
   chsh -s /usr/bin/zsh $USER
   

2. Start the workspace (first boot)
3. Connect via SSH (or web terminal) after startup completes
4. Run echo $SHELL → shows /bin/bash (wrong)
5. Run grep $USER /etc/passwd → shows /usr/bin/zsh (correct in passwd)

Environment

• Host OS: Ubuntu (workspace image)
• Coder version: v2.x (tested on latest)

Additional Context

• The issue only affects the first boot — subsequent workspace restarts have the correct shell already in /etc/passwd when the agent starts.
• This affects all session types (SSH, web terminal, reconnecting PTY), not just SSH — they all go through CommandEnv() → updateCommandEnv().
• The root cause is that the agent is a long-running process whose os.Environ() is frozen at startup time, and updateCommandEnv()'s first-wins dedup lets this stale value shadow the explicitly-resolved correct value.