session terminal ignores the "shell" config option (always PowerShell on Windows) #51051

Activity

1. ggbdpq commented on Oct 1, 2026

   

   ggbdpq

   on Oct 1, 2026

   More actions

   I'd like to work on this.

   Confirmed the diagnosis is still accurate on the current v2 tip (dd786c62af): PersistentPty.Service.create (packages/core/src/persistent-pty/index.ts) still falls back to the free function ShellSelect.environment(global.bin), which reads only process.env.SHELL and drops the options slot, so the configured shell never reaches session terminals. Every other entry point (pty.ts, shell.ts, command execution) already resolves through ShellSelect.Service.resolve({ priority: "config" }).

   Plan: in PersistentPtyHandler's persistentPty.create handler, resolve the configured shell via ShellSelect.Service (same layering handlers/config.ts already uses) and pass it down as command when the payload omits one, keeping PersistentPty itself process-global as suggested. Will include a regression test that fails before the change.
2. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   More actions

   Thanks for the careful write-up. I reproduced this on Linux with 2.0.15, using the same path you traced. The script, screenshot and recording are attached below.

   Setup: "shell": "/bin/dash" in the project config, with SHELL=/bin/bash.

   • The agent's shell tool ran echo "SHELL_EXE=$(readlink /proc/$$/exe)" in dash, which is the configured shell.
   • A session terminal opened in the same session (ctrl+x t) printed bash, so it fell back to $SHELL and ignored the config.

   It still happens on 2.2.0, the latest release. I couldn't run current dev from source, but the code there (fa1260d) is unchanged: persistent-pty/index.ts still falls back to ShellSelect.environment(), which only reads $SHELL. On Windows, where SHELL is usually unset, that gives you PowerShell, as you described.

   Related: #51994 (terminal shell settings shared between Local and WSL servers) and #57310 (gitbash() falling back to pwsh).

   recording.mp4

   

   Reproduction script (drive.ts)

   // Repro for anomalyco/opencode#51051: session terminal ignores the `shell` config option.
   // Configured shell: /bin/dash. Ambient $SHELL: /bin/bash.
   // The agent's shell tool runs in dash; the session terminal opens bash.
   import { Effect } from "effect"
   import { Llm, OpenCodeDriver } from "opencode-drive"
   
   process.env.SHELL = "/bin/bash"
   const probe = 'echo "SHELL_EXE=$(readlink /proc/$$/exe)"'
   
   export default OpenCodeDriver.use(
     {
       ...(process.env.OC_DEV ? { opencode: { dev: process.env.OC_DEV } } : {}),
       config: { shell: "/bin/dash" },
       project: { git: true },
       tui: { recording: true },
     },
     ({ ui, llm }) =>
       Effect.gen(function* () {
         // 1. Agent shell tool (real implementation) -> configured shell
         yield* llm.queue(
           Llm.toolCall({ index: 0, id: "call_probe", name: "shell", input: { command: probe, description: "probe shell" } }),
           Llm.finish("tool-calls"),
         )
         yield* llm.queue(Llm.text("Done probing."))
         yield* ui.submit("Which shell runs your commands?")
         yield* ui.waitFor("Done probing.", { timeout: 30000 })
         yield* Effect.sleep(1000)
         yield* ui.screenshot("agent-shell")
   
         // 2. Session terminal -> should also be the configured shell
         yield* ui.press("x", { ctrl: true })
         yield* ui.press("t")
         yield* Effect.sleep(3000)
         yield* ui.type(probe)
         yield* ui.enter()
         yield* Effect.sleep(3000)
         yield* ui.screenshot("session-terminal")
         const frame = yield* ui.capture()
         yield* Effect.log(JSON.stringify(frame).match(/SHELL_EXE=[^"\\ ]*/g))
       }),
   )

   Run it with opencode-drive: opencode-drive run ./drive.ts. It drives opencode from your PATH; set OC_DEV to the path of an OpenCode checkout to run that from source instead.
3. opencodejr

   added

   reproduced

   on Oct 28, 2026
4. Tsuki-hash commented on Oct 28, 2026

   

   Tsuki-hash

   on Oct 28, 2026

   Author

   More actions

   Thanks for the detailed reproduction — this confirms the issue is still live on 2.2.0.

   For reference, #51052 (fix(server): resolve the configured shell for session terminals) implements exactly this fix: session terminals resolve the configured shell instead of falling back to $SHELL. It was closed by the automated cleanup (age + reaction count), not on its merits, and it still merges cleanly against the current dev tip.

   Would a maintainer be able to reopen #51052, or would you prefer I open a fresh PR? Happy to do either.
5. WuJunkai2004 commented on Nov 3, 2026

   

   WuJunkai2004

   on Nov 3, 2026

   Last edited by WuJunkai2004

   More actions

   why this issues is created in Sep, But in whole Oct, the shell in web works very well? At least in 2.2.2, the terminal I opened in webui, it is followed my setting(git-bash in win).

   But just Now I upgrade opencode to 2.2.5, and find it change back to pwsh :(

   from ai:
   The regression window is 2.2.3 → 2.2.4: PR #60346 (commit ef712d3) moved the desktop terminal to persistent PTYs, and that path resolves the shell via ShellSelect.environment() which ignores the shell config (#51051's root cause).
6. WuJunkai2004

   added a commit that references this issue on Nov 3, 2026

   fix(server): resolve the configured shell in the session location

   ...

   This issue will close once commit ba936f3 is merged into the 'dev' branch.

   ba936f3
7. Tsuki-hash commented on Nov 3, 2026

   

   Tsuki-hash

   on Nov 3, 2026

   Author

   More actions

   @WuJunkai2004 Thanks for the report — this matches the root cause of this issue. #60346 moved the desktop terminal to persistent PTYs, and that path resolves the shell through ShellSelect.environment(), which only reads $SHELL and ignores the configured shell. So the 2.2.5 regression you are seeing is the same bug surfacing on the new path, not a different one.

   For reference, #51052 (fix(server): resolve the configured shell for session terminals) implemented exactly this fix: session terminals resolve the configured shell instead of falling back to $SHELL, and the same approach applies to the persistent PTY path. That PR was closed by the automated cleanup (age + reaction count), not on its merits, and its branch is no longer available — so if maintainers would like this, I am happy to resubmit it as a fresh PR against current dev. Just say the word.
8. WuJunkai2004 commented on Nov 3, 2026

   

   WuJunkai2004

   on Nov 3, 2026

   More actions

   @Tsuki-hash thank you. I try to fix this and take a PR for the issue. It can fix in the new version