Blocking shell/tool call freezes agent — user messages unread until shell unblocks

[renne]

Describe the bug

When the agent executes a bash tool call that blocks indefinitely — for example, an SSH connection to an unreachable host, a network operation waiting for a timeout, or a command that hangs waiting for I/O — the agent becomes completely unresponsive to new user messages until the blocked shell returns.

The user may recognize the problem and send a corrective message (e.g., "stop that", "use a different approach"), but the agent cannot read or act on that message until the blocked call completes. In practice this means the user is locked out of the session for the entire duration of the hang — sometimes 10–15+ minutes.

Additionally, the agent itself has no way to detect that a shell is blocked or cancel it proactively.

Affected version

GitHub Copilot CLI 1.0.18.

Steps to reproduce the behavior

1. Ask the agent to run a command that will block, e.g. SSH to an unreachable host: ssh user@unreachable-host
2. The agent starts the bash tool call with mode="sync" and waits
3. While waiting, send a message such as "stop that" or "use a different approach"
4. Observe: the agent does not respond to the new message at all
5. The agent only resumes when the shell eventually times out — which can take 10–15+ minutes for SSH

Expected behavior

The agent should:

1. Be able to respond to new user messages even while a shell tool call is in progress
2. Ideally: cancel/interrupt a running shell call when the user sends a message asking it to stop, or when a configurable timeout elapses
3. At minimum: surface a visible warning when a call has been running for more than a few seconds ("Shell has been running for 30s, still waiting...")

Additional context

• Workaround: The user can run stop_bash <shellId> to terminate the stalled shell. However, this requires the user to know the shellId and the agent must still be able to read the stop command — which is blocked by the same frozen loop.
• Root cause: Blocking tool calls appear to prevent the message processing loop from handling new input. There is no timeout or interrupt mechanism for individual tool calls.
• User impact: The freeze is indistinguishable from a crash. Users wait many minutes not knowing if the agent is still alive.
• Environment: Linux, bash, x86_64

[MRayermannMSFT]

@renne - when the agent does a mode="sync" shell tool call it is explicitly choosing to wait until that command returns. Have you tried using ctrl+c to stop the agent in this case and then correct it?