Repository navigation
feat(control): expose native terminal draft uncertainty before prompt entry #800
Description
Status (quality-loop audit, 2026-09-25)
Landed: #812: nativeDraft reports occupied only on composer-occupied, otherwise unknown (terminalControl.ts:33).
Remaining: composer-occupied exists only for Claude, so Codex (the reported case) is always unknown.
Acceptance: A Codex composer holding a pre-existing draft is reported occupied, or delivery is refused or preserved; the committed prompt equals the sent prompt.
Original report
In a Codex native terminal, the accessibility Terminal input initially reported no value. After paste it reported the intended status question, but the committed prompt began theWhat do we have left... instead of What do we have left.... This used computer-use paste and Return, not ac_agents_prompt.
The prefix source is unconfirmed: pre-existing native draft or concurrent input are possibilities. The operator failed to reliably establish the full provider draft before pasting. The xterm input accessibility value is not necessarily the complete TUI composer.
Expected/acceptance: expose native draft state where reliable, otherwise report unknown distinctly from empty; prefer typed prompt delivery and preserve/reject occupied provider drafts; document the boundary between app-owned drafts and terminal input transport; validate using a harmless pre-existing draft and the actual committed prompt.
Impact: unnoticed draft text changes the submitted question. This is an observability/workflow gap, not a proven MCP prompt-corruption bug. Related Claude protections: #683, #679.
Environment: macOS, development Electron, two Agent Code windows, external MCP plus computer use, observed 2026-09-05. Exact running build revision was not verified. Refs #793, #795.
Activity
Juliusolsson05 commentedon Sep 5, 2026
Partial support in #812: agents.inputInspect explicitly reports native draft knowledge as unknown where the backend cannot prove it. The guide distinguishes app draft, backend readiness, delivery admission, transport/queue acceptance and committed user text. This does not implement a reliable native composer probe or fix busy-provider admission. Occupied-draft preservation and harmless busy-run/committed-text trials remain outstanding; this is Refs, not Fixes.
feat(control): complete operator search, waits and agent preferences
Juliusolsson05 commentedon Sep 5, 2026
PR #812 now adds structured
agents.prompt/batcherror.details(stage, retrySafe, disposition, promptWritten, enterWritten) and preserves it through the durable journal and MCP envelope. Native input inspection reports provider-knowncomposer-occupiedas occupied, with no invented full text; otherwise it remains unknown. Claude prepared image paths are supported and other providers reject them before wake/send.Provider-boundary and actual MCP schema/transport checks pass at
961d542e. This does not prove the original occupied/busy native UI scenario fixed: full native composer text and universal busy-provider queue admission remain unavailable, and the committed-text trial is still outstanding. #812 references this issue rather than closing it. Two independent orchestration reviews and final CI are in progress.fix(browser-pocket): preserve native drafts and recovery receipts
docs(quality-loop): progress 13:45 — #63 merged, #1314, q36, #800/#1313…
Juliusolsson05 commentedon Sep 27, 2026
#1319 (Refs, not Fixes) covers most of this issue. It stays open for one remaining case.
Covered by #1319 (at
c58234aa):drafted) publishescomposer-occupied. Orchestration delivery refuses with no write, and Enter/Send in Agent Code's composer refuses too.unknown) is also refused by orchestration delivery, and never latches occupied.Remaining (tracked in #1327):
A 13-row pre-existing native draft reads
unknown, because it exceeds the composer classifier's 12-row bound. Readiness then publishesprovider-not-ready, notcomposer-occupied. Enter in Agent Code's own composer only refuses oncomposer-occupied, so it still writes bracketed paste +\r. That appends the new prompt to the human's draft and submits both. The committed prompt then differs from the sent prompt, which fails this issue's acceptance.Evidence:
temp/review-1319/round2-report-a.mdfinding 1 (renderer probe:inputReadinessReason: 'provider-not-ready',sendcalled with\x1b[200~Status?\x1b[201~\r).This issue can close when #1327 lands a separate "unreadable draft" readiness reason that the pane's Enter guard also refuses.
Merge pull request #1319 from Juliusolsson05/fix/codex-composer-occup…
Juliusolsson05 commentedon Sep 27, 2026
Closing: the reported case is fixed; the narrow leftover is tracked in #1327 (triage 2026-09-27, main
a70403ef).