Describe the bug
When the user's configured shell is fish, the CLI's Bash tool wraps each command with a command-completion / exit-code sentinel that uses bash syntax ($?). fish does not support $? (it uses $status), so the sentinel line errors out in fish.
This has two harmful effects:
- Exit-code detection breaks — the wrapper can no longer reliably parse the command's exit status (the agent sees a spurious/invalid exit code such as
-1 on every command).
- Subsequent commands get polluted — the failed sentinel evaluation can leak into the next prompt/command in the same session.
The practical result is that an agent operating in a fish session is pushed toward abandoning the user's shell entirely (e.g. running exec bash) just to get reliable exit codes — which silently overrides the user's chosen shell and any fish-specific environment/config.
Affected version
1.0.49 (session runtime that exhibited the behavior); installed binary now reports GitHub Copilot CLI 1.0.57-5. Behavior reproduces across both.
Steps to reproduce the behavior
- Configure the shell used by the Bash tool to be fish (
fish, version 3.7.1).
- Have the agent run any simple command, e.g.
echo hello.
- Observe that the appended completion sentinel uses
$? (bash) rather than $status (fish), so fish emits an error for the sentinel line and the reported exit code is invalid (e.g. -1), even though the command itself succeeded.
Expected behavior
The completion/exit-code sentinel should be shell-aware:
- Detect the active shell (or the shell configured for the Bash tool) and emit the correct exit-status expansion —
$status for fish, $? for POSIX shells (bash/zsh/sh).
- Exit-code detection should work correctly in fish so the agent can stay in the user's configured shell instead of switching to bash as a workaround.
A minimal fix is to branch the sentinel template on shell type (fish → $status, otherwise → $?), or to use a shell-agnostic mechanism for capturing the exit code.
Additional context
- Operating system: Linux (
Linux 6.8.0-124-generic x86_64)
- CPU architecture: x86_64
- Shell: fish 3.7.1
- Impact: while a command's stdout/stderr is still captured correctly, the invalid exit code defeats success/failure detection and nudges agents into overriding the user's shell choice.
Describe the bug
When the user's configured shell is fish, the CLI's Bash tool wraps each command with a command-completion / exit-code sentinel that uses bash syntax (
$?). fish does not support$?(it uses$status), so the sentinel line errors out in fish.This has two harmful effects:
-1on every command).The practical result is that an agent operating in a fish session is pushed toward abandoning the user's shell entirely (e.g. running
exec bash) just to get reliable exit codes — which silently overrides the user's chosen shell and any fish-specific environment/config.Affected version
1.0.49(session runtime that exhibited the behavior); installed binary now reportsGitHub Copilot CLI 1.0.57-5. Behavior reproduces across both.Steps to reproduce the behavior
fish, version 3.7.1).echo hello.$?(bash) rather than$status(fish), so fish emits an error for the sentinel line and the reported exit code is invalid (e.g.-1), even though the command itself succeeded.Expected behavior
The completion/exit-code sentinel should be shell-aware:
$statusfor fish,$?for POSIX shells (bash/zsh/sh).A minimal fix is to branch the sentinel template on shell type (fish →
$status, otherwise →$?), or to use a shell-agnostic mechanism for capturing the exit code.Additional context
Linux 6.8.0-124-generic x86_64)