What happened?
When a subagent is running and shows the compact +N more tool calls (ctrl+e to expand) hint, pressing ctrl+e does nothing. The shortcut is silently ignored — the agent display stays in compact mode and never expands.
Same for ctrl+f while the agent is running.
What did you expect to happen?
Pressing ctrl+e on a running agent should expand its display from compact to default (showing the task detail and full tool-call list), just like the on-screen hint advertises. ctrl+f should expand further into verbose mode.
Client information
Client Information
Run qwen to enter the interactive CLI, then run the /about command.
$ qwen /about
# paste output here
Platform: macOS
Login information
N/A — bug reproduces under any auth.
Anything else we need to know?
Likely root cause: #3721 added an isFocused guard to the agent display's keyboard listener so parallel running subagents would not toggle in lock-step. But the isFocused value it reused is actually the confirmation focus lock — that flag is only set when a subagent is asking for tool approval. For a normally-running subagent with no approval pending, isFocused is always false, so the keyboard listener stays off and ctrl+e / ctrl+f never fire.
A separate signal is needed for "this subagent owns the keyboard shortcuts" so the parallel-run guard does not accidentally disable shortcuts in the common single-agent case.
What happened?
When a subagent is running and shows the compact
+N more tool calls (ctrl+e to expand)hint, pressing ctrl+e does nothing. The shortcut is silently ignored — the agent display stays in compact mode and never expands.Same for ctrl+f while the agent is running.
What did you expect to happen?
Pressing ctrl+e on a running agent should expand its display from compact to default (showing the task detail and full tool-call list), just like the on-screen hint advertises. ctrl+f should expand further into verbose mode.
Client information
Client Information
Run
qwento enter the interactive CLI, then run the/aboutcommand.Platform: macOS
Login information
N/A — bug reproduces under any auth.
Anything else we need to know?
Likely root cause: #3721 added an
isFocusedguard to the agent display's keyboard listener so parallel running subagents would not toggle in lock-step. But theisFocusedvalue it reused is actually the confirmation focus lock — that flag is only set when a subagent is asking for tool approval. For a normally-running subagent with no approval pending,isFocusedis always false, so the keyboard listener stays off and ctrl+e / ctrl+f never fire.A separate signal is needed for "this subagent owns the keyboard shortcuts" so the parallel-run guard does not accidentally disable shortcuts in the common single-agent case.