anthropics / anthropics/claude-code
[FEATURE] Stage questions with their captured context while Claude Code is working, review the queue before it's consumed
- Dominant language
- Python
- Stars
- 145k
- Forks
- 23.1k
- PR merge metrics
- PR metrics pending
Description
### Preflight Checklist
- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
### Problem Statement
When Claude Code is running a long task, questions pile up faster than I can act on them without derailing it.
Two kinds of questions:
1. **About output that just scrolled by.** Claude prints a decision, a diff, a stack trace, a test failure. I have a question
about *that specific thing*. By the time the turn ends, it's 300 lines up the scrollback.
2. **From outside the terminal.** I'm reading the library's docs in a browser, or looking at the failing assertion in my editor,
or a Grafana panel, while the agent works. The question is about something Claude never printed.
Today my options are all bad:
- **Interrupt with `Esc`.** Reliably kills the agent's momentum. If it was mid-plan on a multi-file refactor, I've paid a real
cost to ask something that could have waited 90 seconds.
- **Type into the queue while it works.** This is the closest thing that exists, but the message is bare text. I have to
*re-describe* the output I'm asking about — "that error you printed about the auth middleware, the second one" — because I can't
point at it. And once typed, I can't review, edit, reorder, or drop it before Claude consumes it. Half-formed thoughts get sent
verbatim.
- **Keep a scratch file.** The question and the thing it's about get separated, and I have to manually reassemble both later.
The common failure is the same in all three: **the question and the context that provoked it get divorced.** Either I interrupt
to preserve the pairing, or I preserve the flow and lose the pairing.
What I want is to keep working — and keep reading — while the agent works, capture questions *with what provoked them still
attached*, and have them land when the agent is actually ready to answer.
### Proposed Solution
A staging queue for questions that carries context with each item, and that I can review before it's consumed.
**Capturing**
- A keybinding (say `Ctrl-Q`) while a turn is running opens a small compose prompt that does **not** interrupt the turn.
- It pre-attaches context: the current terminal selection if there is one, otherwise a capturable slice of recent output (last
tool result, last diff, last error block).
- If I have text on the clipboard from a browser or my editor, I can stage that as the context instead — so a question about
something Claude never printed still arrives with the thing it's about.
- Write the question, hit `Esc`, and I'm back to watching the agent. Nothing is sent yet.
**Reviewing**
- `/queue` shows the staged items — question plus a collapsed preview of its attached context.
- Edit, reorder, merge, or delete any item before it goes out. This is the part typing-ahead doesn't give me: a chance to drop
the question that answered itself two minutes later.
**Delivering**
- By default the queue flushes when the current turn completes, delivered as one message so Claude sees all of it together and
can answer coherently rather than serially.
- `/queue send` to flush immediately, `/queue clear` to drop everything.
- A setting for whether flush is automatic or always manual.
Each item arrives with its context inline, roughly:
> **Q:** Why did this fall back to the sync path instead of erroring?
> ```
> [captured from output at 14:22]
> warn: async transport unavailable, falling back
> ```
**Key property:** staging must never touch the running turn. No interrupt, no re-render that disturbs the agent, no partial input
landing in the transcript.
### Alternative Solutions
Alternative Solutions
**Typing into the existing message queue while Claude works.** The closest built-in behavior, and the reason I want to be precise
about what's missing — this request is the delta, not a replacement:
- The queued message is bare text with no attached context, so I have to re-describe output that's already on screen.
- No review step. Once typed it will be consumed as-is; I can't edit, reorder, or drop it.
- Nothing outside the terminal can enter it — a question about a browser tab has to be typed out from scratch.
**`Esc` to interrupt, ask, resume.** Works, costs the agent's working state. Fine once, expensive as a habit.
**Scratch file / notes app, paste at the end.** Preserves the flow, loses the pairing, and I do the reassembly by hand.
**I built a workaround for this** — a macOS menu-bar app that captures the current selection from *any* app, pairs it with a
typed question, queues them, and pastes the batch into the verified terminal when the agent is ready. It's been genuinely useful,
which is why I'm filing this.
But an external tool hits a ceiling that only an in-product version clears:
- It drives the TUI by synthesizing keystrokes via the Accessibility API — fragile, needs a permission grant, and it has to guess
which terminal window is the right destination.
- It has no visibility into session state, so "is the agent ready?" is inferred from the outside instead of known.
- It's macOS-only, and the problem isn't.
A `claude`-side queue would need none of that, and would let external capture tools push into a supported entry point instead of
impersonating a keyboard.
### Priority
Medium - Would be very helpful
### Feature Category
Interactive mode (TUI)
### Use Case Example
**Scenario: a 6-minute dependency migration across ~20 files.**
1. I ask Claude Code to migrate our HTTP client from `requests` to `httpx` across the service. It starts working — reading files,
editing, running tests. This will take several minutes.
2. Two minutes in, it prints that it's converting a retry wrapper to `httpx`'s transport-level retries. I have a question about
whether that preserves our jitter behavior, but interrupting now would drop it mid-file.
→ I select those output lines, press `Ctrl-Q`, type *"does this preserve the jitter config from the old wrapper?"*, press
`Esc`. Claude keeps working, uninterrupted.
3. While it works I'm reading the `httpx` docs in my browser and find a note about connection-pool limits differing from
`requests`. Claude never printed this — it's context from outside entirely.
→ I copy the paragraph, press `Ctrl-Q`, stage it with *"do we need to set explicit pool limits given this?"*.
4. A minute later a test failure scrolls past about a mocked adapter. Same move: select, `Ctrl-Q`, *"is this mock still valid or
should it be rewritten?"*
5. The migration finishes. Before anything is sent I run `/queue` — three items. Item 3 answered itself; Claude already fixed
that mock two steps later. I delete it. I tighten the wording on item 1.
6. `/queue send`. Claude receives both remaining questions **with the exact output and the exact doc paragraph attached**, and
answers them together against the finished migration.
**What this saves:** I asked three questions across six minutes without a single interrupt, without retyping any context, and
without sending the one question that had gone stale. Today that same session is either three interrupts and a broken-up
migration, or three vaguely-worded queued messages I have to spend a follow-up turn clarifying.
### Additional Context
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the existing message queue in interactive mode (TUI) and the `/queue` command. Review how input is handled while a turn is running, then determine how staged questions could retain captured context and remain separate from the active transcript. Done should cover review, editing, deletion, and delivery after the turn completes without interrupting it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100