Describe the bug
ctrl+x → b ("move current task to background") does not work when the agent is blocked inside a read_bash call with a nonzero delay , even though the underlying shell command was already started with mode: "async" .
Repro: agent runs bash { command, mode: "async" } to start a long command, then calls read_bash { shellId, delay: 150 } to wait on it. Pressing ctrl+x → b during that 150s wait returns "No running sync task to move to background." There is no way to interrupt or background this — the session appears frozen with no escape hatch, which is worse than a plain mode: "sync" call (which presumably is backgroundable via the same keybind).
Expected: ctrl+x → b should also detect and background/interrupt a blocking read_bash (or any tool call) that's been running past some threshold, not just a live bash mode=sync invocation.
Affected version
GitHub Copilot CLI 1.0.70.
Steps to reproduce the behavior
- Start a Copilot CLI session.
- Have the agent run a shell command in background mode, e.g. equivalent of:
bash { command: "sleep 150", mode: "async" }
This returns a `shellId` immediately (command is now running detached in the background).
- Immediately have the agent call:
read_bash { shellId: , delay: 150 }
This blocks the agent's tool call — and the interactive session — for the full 150 seconds while it waits to read output.
- While that read_bash call is still pending/blocking (i.e., before the 150s elapses and before the agent's turn produces any further output), press ctrl+x → b to try to move the current task to background.
Expected behavior
The current task (the agent's blocked turn) is moved to background, session control returns to the user, and the job can be checked later via /tasks .
Additional context
Actual result: The keybind reports "No running sync task to move to background" — even though the session is visibly blocked/unresponsive for the full 150-second duration. There is no live, backgroundable "task" for the CLI to detect, because the underlying shell command ( sleep 150 ) was already async — only the agent's read_bash wait is blocking, and that isn't recognized as a task the keybind can act on.
Additional note: This was verified in contrast to a (not yet independently confirmed, but documented-as-working) genuine bash mode="sync" call — the bug is specific to the read_bash -poll blocking pattern, which is the more dangerous case since it currently has no user-facing escape hatch at all.
Describe the bug
ctrl+x → b ("move current task to background") does not work when the agent is blocked inside a read_bash call with a nonzero delay , even though the underlying shell command was already started with mode: "async" .
Repro: agent runs bash { command, mode: "async" } to start a long command, then calls read_bash { shellId, delay: 150 } to wait on it. Pressing ctrl+x → b during that 150s wait returns "No running sync task to move to background." There is no way to interrupt or background this — the session appears frozen with no escape hatch, which is worse than a plain mode: "sync" call (which presumably is backgroundable via the same keybind).
Expected: ctrl+x → b should also detect and background/interrupt a blocking read_bash (or any tool call) that's been running past some threshold, not just a live bash mode=sync invocation.
Affected version
GitHub Copilot CLI 1.0.70.
Steps to reproduce the behavior
bash { command: "sleep 150", mode: "async" }
This returns a `shellId` immediately (command is now running detached in the background).read_bash { shellId: , delay: 150 }
This blocks the agent's tool call — and the interactive session — for the full 150 seconds while it waits to read output.Expected behavior
The current task (the agent's blocked turn) is moved to background, session control returns to the user, and the job can be checked later via /tasks .
Additional context
Actual result: The keybind reports "No running sync task to move to background" — even though the session is visibly blocked/unresponsive for the full 150-second duration. There is no live, backgroundable "task" for the CLI to detect, because the underlying shell command ( sleep 150 ) was already async — only the agent's read_bash wait is blocking, and that isn't recognized as a task the keybind can act on.
Additional note: This was verified in contrast to a (not yet independently confirmed, but documented-as-working) genuine bash mode="sync" call — the bug is specific to the read_bash -poll blocking pattern, which is the more dangerous case since it currently has no user-facing escape hatch at all.