Feature request: `/btw` side-channel for asking questions without interrupting an active run

[dreamfarer-space]

Feature Description

Add a lightweight side-channel (for example /btw, a small secondary prompt, or an equivalent TUI panel) that lets the user ask a question while the main agent is actively running, without interrupting, steering, cancelling, or queueing a new turn into that run.

The key requirement is that this side conversation should be observational and non-destructive: the foreground task keeps running exactly as-is, while the user can ask things such as:

• "What step are you on right now?"
• "Which year/file are you processing?"
• "What remains after the current step?"
• "Are the background/sub-agents still running?"
• "What was the last completed action?"

A response could be based on the current task/todo state, recent tool activity, active sub-agents/background jobs, and any already-written files. It should not inject the side question into the main model context unless the user explicitly chooses to do so.

Use Case

For long autonomous tasks, the current UX makes it hard to check progress without disturbing execution. For example, if Command Code is processing a large multi-year dataset or editing many files, I may want to know whether it has reached 2018, 2020, etc. while letting the main run continue uninterrupted.

Today the closest workarounds are:

1. Open a second Command Code session in the same project and ask it to inspect the filesystem read-only.
2. Use the Background panel for shell tasks.
3. Poll sub-agent status where available.

These are useful but not equivalent. A second session has no direct view of the foreground run's internal task/todo state, and the Background panel is primarily about background work rather than the active foreground agent.

A /btw-style side-channel would make long-running sessions much easier to supervise without changing their behavior.

Possible UX

One possible design:

/btw what step are you on?

or a keyboard shortcut that opens a small temporary prompt/panel over the TUI.

The answer could show a compact snapshot such as:

Main run: active
Current task: Processing 2019 exam solutions
Last completed: 2018.md + 6 cropped images
Remaining: 2020-2023
Background agents: 2 running

Important semantics:

• Does not interrupt or cancel the active run.
• Does not become a steering message by default.
• Does not alter the active run's context/todos.
• Can inspect current run state and already-observable project state.
• Optional action to "send this to the main run" if the user actually wants to steer it.

Additional Context

There are related issues around background-agent visibility (for example #874), but this request is specifically about a side conversation/status query for an active foreground run, rather than improving the telemetry of detached sub-agents.

This pattern is especially useful for long autonomous coding/data-processing tasks where users want supervision without interference.

[dreamfarer-space]

I looked into whether this could already be implemented entirely as a Mod. It looks like most of the building blocks are there, but one small core capability is missing.

A Mod can already:

• register a custom slash command with cmd.addCommand()
• observe run/turn/tool/sub-agent activity and maintain a live snapshot of what the agent is doing
• render passive status UI via the Mod UI APIs

That is enough to build the actual /btw logic (e.g. keep currentTool, lastCompleted, current turn, active sub-agents, etc.) without touching the main agent context.

The blocker is the TUI's busy-state command gate: a custom Mod command cannot opt into the small set of commands that are allowed while the foreground run is active. So /btw can exist as a Mod, but it cannot be invoked at the exact moment it is most useful.

A minimal implementation path may therefore be to expose something like:

cmd.addCommand({
  name: 'btw',
  description: 'Show current run status',
  allowWhileBusy: true,
  readOnly: true,
  handler: ...,
})

or an equivalent API for registering a busy-safe/read-only command.

If allowWhileBusy is considered too broad, it could be restricted to handlers that cannot enqueue a model turn, mutate the active run, or call mutating tools. That would let Mods implement the side-channel/status UX themselves while keeping the foreground run isolated.

So this may not require a whole new side-conversation subsystem initially — exposing a safe busy-time command hook could be enough for the community to prototype /btw and similar supervision tools.