Give the model provenance & timing context for user input (bang commands + queued/in-flight prompts)

Two related gaps where the model lacks context about how and when user input arrived. Both cause avoidable confusion, and both stem from the same root: the model gets user input with no provenance or timing.

Part 1 — ! bang-command provenance

When a user runs a shell command via ! in Claude Code, the command and its output are injected into the model's context (as bash-input / bash-stdout) with no metadata about where it came from or why. The model can't tell:

• that it was a user-initiated bang command (vs. output from another surface),
• whether a response is wanted or the user just ran it for themselves,
• any intent behind it.

It's also ambiguous: a trailing shell-prompt line (e.g. user@host ~ %) makes a bang command look like output from a separate persistent terminal pane — which the model does not see. In one session this led the model to confidently misattribute a brew help dump to the wrong source and invent a narrative for why it appeared.

Request: tag bang-command injections with lightweight provenance — e.g. a source: user-bang marker or an [informational unless the user asks] hint — keep the invoked command distinct from its output, and optionally let the user attach a one-line note.

Part 2 — queued / in-flight prompts

A user often composes a reply while the assistant's response is still streaming, and the app delivers that queued prompt when the turn ends. The model receives it appended after its own completed reply, with no indication that it was composed before that reply existed (and may never have been seen). Result: the model redundantly re-answers, or produces a reply that appears to ignore its own message — which reads to the user as the model not paying attention.

Inspecting local session transcripts (JSONL) confirms the only timing field persisted is a single delivery timestamp — the compose/queue time is never recorded at any layer, so the model can't detect this even in principle.

Request: capture and expose timing/provenance for queued prompts — e.g. composed_at, delivered_at, and composed_against_message_id — so the model can recognize a prompt may be "stale" and reconcile gracefully ("you may have sent this while I was still replying — here's how it fits") instead of repeating itself or appearing to ignore the user.

Illustration (constructed, but representative)

user: Do they still have that mystery house in California? do you know what it's called? assistant (after ~4 minutes of research): Yes! It's the Winchester Mystery House in San Jose. Website: winchestermysteryhouse.com. Tickets at /tours/, plus a dedicated virtual-tour site. Want me to draft an email to them or dig into the history? user (queued ~30s into the 4-minute turn, delivered at the end): I think it's this place: winchestermysteryhouse.com — can you confirm?

The queued prompt asks the model to confirm a URL the finished response already found, linked, and built an entire answer around. Without timing context, the model either redundantly re-confirms or the exchange reads as the user ignoring a detailed answer. With the metadata, it could instead say: "You sent that while I was still researching — yes, that's exactly it; details above."

Note

Both parts are the same underlying gap: the model lacks provenance/timing on user input. For Part 2 I built a local UserPromptSubmit hook that flags prompts delivered within a few seconds of a long reply finishing (the queued-mid-stream signature) and injects a heads-up — but that only works by reverse-engineering timing the app discards. Native metadata would be far more reliable.

Environment: Claude Code (desktop app).