ctrl+x → b  fails to background/interrupt a blocking  read_bash  call (no escape hatch when polling an async command)

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

1. Start a Copilot CLI session.
2. 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).
3. 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.
4. 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.

Empieza por el manejo del atajo de teclas ctrl+x → b y sigue cómo identifica una tarea en ejecución; después sigue la ruta read_bash para un delay distinto de cero después de que bash mode="async" devuelva un shellId. Reproduce el problema con sleep 150 y delay 150. Se considera terminado cuando el turno bloqueado se puede mover al segundo plano, el control regresa y aparece en /tasks sin el error actual.