fix(native-chat): every chat action press is its own action

[brennanb2025]

	Files	Added	Deleted	Net
Test	28	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1313	$\color{#cf222e}{\Huge{\mathbf{−}}}$​237	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1076
Prod	22	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​323	$\color{#cf222e}{\Huge{\mathbf{−}}}$​228	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​95

ELI5

When a chat action failed to get an answer (for example the connection dropped), Orca kept that action's id and quietly reused it the next time you pressed the same thing. The host then treated the new press as a repeat of the old one and did nothing. So picking an option again could leave the chat on the other one, a second Stop could do nothing, and setting a goal again could leave it cleared. Now every press is its own action. A harmless repeat, such as a second Stop of a turn you already stopped, or a second tap on a queued message's Send, is answered from what the chat already records, so it changes nothing and says nothing false.

The plan this belongs to

Goal: one operation id per user action for every structured chat write. Each press is new, only an explicit retry of that one action may reuse an id, and the host answers a harmless repeat from what the chat already records. It ships as:

• Step 1, this PR (stacked on fix(native-chat): /clear starts nothing; the new chat's first message starts its agent #23935): desktop writes, the queued-message buttons and phone Stop get a fresh id per press; no client keeps a retry id; the host answers harmless repeats; a Stop that stopped nothing writes no row. (That last part was planned as a separate follow-on after fix(claude): a Stop naming the running turn acts at once, and a Stop in the gap is no longer lost #23861; this PR now covers it.)
• Step 2, fix(mobile-chat): every phone send is its own message #23917 (stacked on this one): each phone message send gets its own id instead of being keyed by its text.

What Changed

The problem. The desktop app kept operation ids in memory keyed by chat, action and exact payload, and kept one after a dropped connection, an "unknown" answer or a refusal. The next identical press, however much later, reused it, and the host replayed the old outcome instead of running. The phone's Stop and its /compact and /clear did the same. Seen as:

• pick option A (connection drops), pick B, pick A again: the chat stayed on B;
• a Stop naming a turn or a background task, pressed again after a failure: nothing happened;
• set a goal (answer lost), clear it, set it again: it stayed cleared;
• a /compact retyped later, even after newer messages, replayed the old "completed" and did not compact, and on the phone that lasted up to 24 hours.

Scope. Structured Claude and Codex chats, on desktop, paired desktop and phone, local and SSH hosts. That includes the Send, Delete and Resume buttons on messages queued while the agent works (#23731, #23736). Sends on the desktop already used a fresh id per message and are unchanged. Phone sends are step 2.

Before / After

You do	Before	After
Pick A (lost), B, then A again	stays on B	switches to A
Set a goal (lost), clear, set it again	stays cleared	set
Stop again after a failed Stop (desktop named Stop, background task, phone)	nothing happens	stops
Type /clear again after its answer was lost	worked only until the app reloaded; after that "This conversation has been cleared"	the chat moves to the current conversation, nothing new runs, also after a reload
Stop a turn twice by its id (a phone double-tap, or Stop on two devices), at once or a moment apart	a second row, "The provider had already finished this turn.", which is false	one "Cancellation requested." row
Stop a turn that already ended by itself	"The provider had already finished this turn."	no row; nothing was stopped
Press /compact again while the first waits or runs	answered from the kept id	refused: "Wait for the current turn to finish before using this command."; it runs once
Press /compact again after the first ended	answered from the kept id, even after newer messages	runs again
Press /clear again while the first is still running	answered from the kept id	refused: "Wait for the conversation operation to finish."; one new conversation
Tap a queued message's Send, Delete or Resume twice	answered from the id shared by the two taps	each tap has its own id; the second is answered from the card's state: already sent, already gone, or nothing left to resume

Mechanism

• Renderer use-structured-agent-session-mutate.ts: every call mints its own id. The per-payload id map, the kept /compact and /clear id, and the shared "does this write name its target" check (structured-agent-session-operation-identity.ts) are deleted.
• Mobile: Stop, the composer command and the queued-message buttons mint a fresh id per press (use-mobile-structured-agent-mutation.ts, use-mobile-structured-send-with-outcome.ts); the id-retention helpers are deleted.
• Host, where a repeat is harmless, answers from what the chat records:
  • the same answer to a question already answered that way returns the stored answer (structured-agent-session-turns-prompt.ts);
  • Cancel of a question already cancelled answers ok (structured-agent-session-turns-cancel.ts);
  • a /clear from the same client after its /clear committed, with no tab left on the old conversation, returns that clear's result, replacement included, before anything starts (structured-conversation-command.ts). Only a successful clear counts; another client, or a cleared conversation reopened from history, still reads "cleared".
  • a Stop that stopped nothing writes no row (structured-agent-session-turns-cancel.ts). "The provider had already finished this turn." is gone. The one "Cancellation requested." note is keyed by the turn it stopped, found by the turn's id whether it still runs or has ended (structured-agent-session-turn-stop-notes.ts), so another Stop of that turn rewrites that row instead of adding one. A Stop that didn't do what was asked still says so: the refusal row while the turn keeps running, and "Cancellation was not confirmed." when the adapter failed.
  • a second /compact or /clear while the first waits or runs is refused by the existing gates, with the existing lines; one pressed after it ended runs again. A retry of the same operation id is answered from what it already wrote (the ledger replay, unchanged).
  • a second Send, Delete or Resume of a queued message: an already-sent card answers with the submission it made, an already-deleted one with "already withdrawn", and a Resume with nothing paused with "resumed nothing" (structured-agent-session-queued-mutations.ts, unchanged; now pinned by tests).
• A new host capability, agent-session.repeated-stop.v1, says the host writes no row for a Stop that stopped nothing, so a repeated Stop is quiet. The desktop and phone check it, and against a host without it, each still joins a second Stop of a turn to one already on its way, as before this PR, so an older host never writes the false row.
• The three capabilities that gate a Stop (conversation-stop, prompt-cancel and the new repeated-stop) moved together into src/shared/agent-session-stop-capabilities.ts. protocol-version.ts re-exports them, so no importer changes. Main had filled that file to its line limit, and this keeps one Stop's wire rules in one place instead of trimming unrelated lines.
• Nothing new is saved. The only change on the wire is that one capability string.

Why

A press is a user action, and an action's identity cannot be inferred from its payload: the same pick an hour later is a new choice. Retries of one action stay possible where a stored record of that action exists (a desktop message's outbox entry; #23524's host-side /clear retry), so the client never has to keep an id it can't re-derive. Repeats that are harmless are answered from state the host already holds, not from a remembered id.

Alternatives considered:

• Keep the id only while the host says the action is unconfirmed. Built and reviewed twice; it could still replay an old "completed" after another window's command, and it was lost on reload.
• The host resuming an unfinished /clear from a saved record. Dropped: fix(native-chat): an unfinished /clear or refused Codex rewind no longer locks the chat #23524 removes that saved record and finds the earlier attempt's work statelessly, which works with fresh ids.

Differences from the common pattern

• A common approach mints a random command id per call and replays only an identical id, and records that id on every event it produces. This PR matches the per-call id and the exact-id replay. It does not record the id on every chat row, because nothing here needs to answer "which press made this row", and it would add a stored field to every row.
• Matches: a Stop is recorded at the time it takes effect and only when it takes effect. One common approach writes its interrupted row in the same transaction that moves the thread to stopping, and a Stop that applies to nothing (already stopping, or idle) writes nothing. The other upserts the turn, keyed by turn id, to interrupted. Here the one note is written on the provider's answer to the interrupt, keyed by turn, and a Stop that stopped nothing writes nothing.
• Matches: a failed Stop still says so. A common approach appends an "interrupt failed" activity when the interrupt fails or no session is bound. Here the refusal row and "Cancellation was not confirmed." stay.
• Matches: /compact and /clear: each press has its own id, only a replay of the same id is answered from its record, a press while one runs or a turn is active is refused by state, and a later press runs again. That is how both common approaches handle them.
• Intended: a common approach also joins concurrent Stops per thread in memory. Here two Stops at once reach the host one after the other on the session's lane, and the second either stops nothing, writing nothing, or rewrites the same turn-keyed row, so no join is needed on a current host.
• Temporary: the desktop and the phone still join a second Stop of a turn to one on its way when the host lacks agent-session.repeated-stop.v1. It exists only so a new app talking to an older host doesn't write the false row. The follow-up deletes both client joins once no supported host lacks that capability.

Linked Issue

No issue. Found while fixing Stop and send delivery in #23026 and #23553.

Visual Proof

A Stop of a turn, sent twice under separate ids, and a Stop of a turn that already ended. A double Stop under separate ids is what a phone double-tap sends, or Stop pressed on two devices. Live on a second Mac with the real Claude CLI 2.1.285, in a production-renderer build driven over CDP. Two arms, each proven from its built bundle:

• before: this PR's base, fix(native-chat): /clear starts nothing; the new chat's first message starts its agent #23935 at d4e7d53c7bd, where "The provider had already finished this turn." appears twice in the main bundle;
• after: this PR at 8867990f21d, where it appears 0 times and the capability string 4 times.
  Each Stop goes through the host's own agentSession.cancel from the page, naming the running turn. The rows below were also read back from each arm's journal. After this PR, the note's key is the turn id, and it is written once per stopped turn.

Case	Before	After
Two Stops at once	"Cancellation requested." then "The provider had already finished this turn."	one "Cancellation requested."
The second Stop 1.5 s after the first one answered (the slow-link case)	the same two rows	one "Cancellation requested."
A Stop naming a turn that had already ended by itself	"The provider had already finished this turn."	no row
The desktop's own Stop button double-clicked (it names no turn)	one row	one row

Before, two Stops at once: the false line under the stopped reply:

Before, the second Stop 1.5 s after the first had answered:

After, both at once and 1.5 s apart: no false line. The two runs stopped at the same point and rendered identically, so one image shows both:

Before, a Stop naming a turn that had already finished:

After, the same Stop writes nothing:

Phone QA: BLOCKED. The emulator QA skill this needs can only be started by a person, not by this session, and no other way of driving the phone is used in its place. So these phone checks were not run live: overlapping taps on a queued message's Send, Stop tapped twice against this PR's host, and the phone's Stop against a host without agent-session.repeated-stop.v1. The 68 mobile tests above cover them, including the phone's Stop join against a host without the capability, and both presses going out against one with it.

Earlier heads: nothing regressed. Live QA with the real Claude CLI on a second Mac, in a production-renderer build, driven over CDP. Three arms: this PR before its last rebase (09fa9e908eb), its base (f26e8039693), and the current head (89564af9862) for the /clear cases, each proven from its built bundle. Everything the app can produce behaves the same on every arm, so these runs show nothing regressed. The cases this PR fixes all need a lost reply, which the app cannot produce on demand; the tests below cover them.

Scenario	Result, every arm
Stop pressed twice	the reply stops, one Stop row, no error (at 110 ms the button is already gone, so the second tap misses)
Model Haiku → Sonnet → Haiku	ends on Haiku, and the next reply ran on Haiku
/clear pressed twice ~27 ms apart	one new conversation, no error, also on a conversation with a finished turn
/clear typed in the old conversation reopened from history	"This conversation has been cleared. The command didn't run. Open the current conversation to continue.", as described above
Question card answered, pressed again	resolves once, no error
"yes" sent twice	both sent and answered

A Stop pressed twice: the reply stops and no error shows:

An option picked A, then B, then A again ends on A:

/clear pressed twice on a conversation with a turn lands on one new, empty conversation (current head):

/clear on a cleared conversation reopened from history still says it was cleared (current head):

The same text sent twice is sent twice, and a question card resolves once:

Testing

• I manually tested these changes locally

• Automated tests added/updated, or explained why not below

• New use-structured-agent-session-mutate.test.tsx (a fake host ledger) and structured-agent-session-repeat-press.test.ts (the real host): an option picked again, a goal set again, a named and a background Stop pressed again, the joined Stop reporting once, and the same answer again.

• structured-conversation-command.test.ts and structured-chat-tab-table.test.ts: a /clear double press and a retype after a lost answer land on the current conversation with nothing started; another client and a reopened conversation still read "cleared"; a failed clear runs fresh.

• structured-agent-session-host.test.ts and -prompt-cancel.test.ts: a second prompt Cancel, sent while the first is in flight or after it, answers quietly and asks the agent once.

• Mobile mobile-structured-composer-command.test.ts and mobile-structured-operation-id-retirement.test.ts: fresh ids per press. Against a host without the capability, Stop joins the one on its way. Against a host with it, both presses go out.

• New structured-agent-session-repeated-stop.test.ts (the real host and journal): a second Stop after the first settled writes nothing; two Stops at once leave one row (keyed by turn; keying by operation id again fails it); a Stop of a turn that ended by itself, or two Stops that both found nothing, write nothing (bringing back "already finished" fails 7 tests); a relaunched host writes nothing more.

• New structured-agent-session-queued-repeat-press.test.ts (the real host): Send, Delete and Resume of a queued message pressed twice under separate ids: sent once, deleted once, resumed once, and the second press answered, not refused. Removing the host's "already sent" answer fails the Send test. Mobile use-mobile-structured-agent-session-queued.test.tsx: overlapping card presses carry their own ids; it fails with main's id sharing.

• structured-conversation-compaction.test.ts and structured-conversation-command.test.ts: a /compact pressed again under a new id while one runs is refused and runs once, and one pressed after it ended runs again; a second /clear pressed while the first runs is refused and makes one new conversation. Joining the same client's /clear instead fails the /clear test.

• Desktop use-structured-agent-session-mutate.test.tsx: the Stop join is used only against a host without the capability; with it, every press goes out under its own id.

• Each new test fails on the base; removing each rule fails its test.

• tc:node, tc:web, the mobile typecheck and its test ratchet, oxlint, check:code-quality:changed, check:react-doctor:changed, the reliability gates and the anti-slop audit pass on the current head. 21 related host and desktop test files (227 tests) and 6 mobile files (68 tests) pass.

AI Disclosure

Review

Four review loops and an architecture challenge.

• Loop 1 found that fresh ids made a quick double Stop or double Cancel write a misleading line; fixed by answering those repeats from what the chat already records, and by joining a Stop still in flight.
• Loops 1 and 2 both found holes in keeping a /compact or /clear id on the client for a retry (it could replay an old "done", and it was lost on reload). Because the same mechanism failed twice, an architecture challenge replaced it: clients keep no retry id at all, and a /clear retry is found by the host (fix(native-chat): an unfinished /clear or refused Codex rewind no longer locks the chat #23524 and fix(native-chat): /clear starts nothing; the new chat's first message starts its agent #23935).
• Loop 3 found only an accidental lockfile change and a doubled error toast, both fixed.
• Final loop after the rebases found no code issues; description wording was corrected.
• After merging main (the queued-message buttons) and adding a host-side Stop join, one more loop found:
  • two P1s, both test-only: five renderer test mocks lacked the new capability export, and one test from main still expected /clear to reuse its id. Both fixed.
  • a P2 in the design: the in-memory join covered only the time the host spent on the first Stop. It was replaced by the journal read described above, and the capability's meaning changed with it.
  • a /compact pressed again after a lost reply could compact twice once the first had finished, and a second /compact or /clear while the first was running showed a refusal line where main was quiet. Both are now answered from the command they repeat, as described above.
• Checked against both reference projects first-hand, after that loop: the in-memory join and the journal lookup were replaced by the shapes above. A Stop records only what it did, keyed by turn; /compact and /clear repeats are refused while one runs and run again after, with only same-id replays answered. The repeat-answer code for /compact and the same-client /clear join were removed.
  • a P3 not changed: the desktop reads the capability from the runtime's status cache before a Stop naming a turn, which can cost one status round trip against a remote host. The desktop names a turn only for background-task Stops and for hosts without the conversation Stop, so this is rare.

Agent skill upstream boundary

• Not applicable, or this change follows docs/reference/agent-skill-sharing-upstream-boundary.md and copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Merge order: #23524, then #23935, then #23916, then #23917.

Mixed versions (clients and hosts update separately):

• A new app with an older host (one without fix(native-chat): an unfinished /clear or refused Codex rewind no longer locks the chat #23524 and fix(native-chat): /clear starts nothing; the new chat's first message starts its agent #23935): if a /clear fails partway, it cannot be finished; sending then says "The last /clear didn't finish. Start a new chat to continue." Before, retyping /clear could finish it until a reload. The only alternative was keeping the client-side id this PR removes.
• A new app with an older host (one without agent-session.repeated-stop.v1): the app joins a second Stop of a turn while the first is on its way, as before. A second Stop pressed after the first one's answer arrived can still write "already finished" there, as can a Stop of a turn that ended by itself. Clicking the same answer again after a lost reply shows "The question changed".
• An older app with a new host: the older app keeps one id for a quick double Stop, and the host replays it. No second row either way.
• With a host from before fix(native-chat): turn facts come from the turn record, and /compact is a message the chat sends #23059, retyping /compact after the app gave up waiting (195 s) while that host was still compacting compacts a second time. A current host refuses it while the first is queued or running.

Follow-ups:

• Delete the desktop and phone Stop joins once no supported host lacks agent-session.repeated-stop.v1 (see Differences, temporary).

Known, not changed here:

• After a /clear whose answer was lost, a pane still showing the old conversation catches up only on its next tab sync; that sync is not covered by a test.

Same on macOS, Linux, Windows and SSH hosts.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

Author: @BrennanKB5

[brennanb2025]

Queued-card review for this PR, from the author of #23726/#23731/#23736. Line numbers are from main 6b36a2c3fb6, src/main/native-chat/agent-session-wire/structured-agent-session-queued-mutations.ts.

Send-now and Delete already decide by the draft's state, not by operation id. A second press with a fresh id is already answered quietly:

• Send-now (sendQueuedStructuredAgentMessage, :175). A draft that is already dispatched answers with the submission it became, not a second send (:210-215). This case needs a red-first test under a fresh id; none exists today.
  • The check at :189-191 (submissionFor(ctx, operationId)) only matches a same-id replay. With fresh ids it simply never matches. That's harmless, and you can keep or drop it.
  • A draft that is missing (:204-205) or withdrawn (:207-208) is refused, and that should stay a refusal. Nothing was sent, so answering "ok" would claim a send that never happened. The card is already gone from the list, so the client can skip the toast if it wants.
• Delete (deleteQueuedStructuredAgentMessage, :267). missing (:280-281) and withdrawn (:286-287) already answer ok, deleted: false. Both are harmless repeats, so they can stay quiet.
  • disposition: 'dispatched' (:283-284) is NOT harmless and must not be silenced. Edit is "copy the text into the composer, then Delete". If the draft went out in between, desktop (use-structured-agent-session-queued-messages.ts:113,136) and phone (use-mobile-structured-queued-message-controls.ts:114) tell the user "Already sent — your text is still in the composer". That's decided by state, not by id reuse.
• Resume (resumeStructuredAgentQueue, :315). It already gets a fresh id on every press on main (structuredAgentSessionWriteNamesItsTarget returns false for it). resumeStructuredQueue (structured-agent-session-queued-pause.ts:99) is a no-op when nothing is paused, so a second press does nothing.
  • One case is not harmless: an automatic retry, after transport doubt, that arrives after a newer Stop. It would lift the new pause. That only matters if the client still auto-retries. The fix by state is for Resume to name the pause it saw: the pause row already has epoch and sequence (queued-message-pause-table.ts), so the host would lift only a matching pause.
• Edit. Client-side copy, then Delete, so it's covered above.

Where id reuse still matters: the send itself. This isn't a card action, but it's the one that creates a draft, and it depends on keeping its id across a retry.

• A mid-turn send becomes a draft whose id is the send's clientMessageId. The draft insert is idempotent on (session, message), and the journal refuses a second submission under an id it already holds (journal_submission_exists). Together those are what make a retried send safe.
• On desktop the outbox sends with clientOperationId: entry.clientMessageId (structured-agent-session-outbox.ts:335) and replays that id after a lost answer.
• On the phone, sends go through useMobileStructuredSendWithOutcome with operationIds, plus the persisted send-operation journal.
• If a retried send gets a fresh id, the host sees a new message: a second queued card, or a duplicate turn.
• So please keep the per-message id (and the phone's saved send record) for agentSession.send, even if the other structured writes move to a fresh id per press. Deleting operationIdsRef on the phone must not take the send's retained id with it.

Other id reuse in the cards. None: Steer, Delete, Edit and Resume don't reuse an id beyond what's listed here. The only other place is the Send-now retry after transport doubt, which is covered by the dispatched answer above, as long as the retry doesn't cross a Stop. A Stop returns a withdrawn hand-off to waiting, so an automatic Send-now retry arriving after that Stop would send it again. That's fine if a retry only ever comes from a press. If the client still auto-retries, that retry has to keep the id.

NEVER merge. Review only.

[brennanb2025]

Status: head 8867990f21d, ready for review. CI green (19 passed, 14 skipped).

Since the last status:

• Merged main (the queued-message buttons from feat(native-chat): mid-turn messages wait as editable cards above the composer #23731 and feat(mobile): mid-turn messages wait as cards above the phone composer #23736) and then fix(native-chat): /clear starts nothing; the new chat's first message starts its agent #23935's updated branch. This PR's diff against fix(native-chat): /clear starts nothing; the new chat's first message starts its agent #23935 is its own 45 files.
• The queued-message buttons (Send, Delete, Resume) get a fresh id per press, as every other write does. A second press is answered from the card's state. That is pinned by host and mobile tests.
• A Stop of a turn an earlier Stop already answered for now adds no row, however late it lands and from whichever device. That answer is read from the earlier Stop's note on the turn, in the journal. An in-memory host join was built first; review showed it missed a second Stop arriving just after the first had settled, so it was replaced.
• Reworked after checking both reference projects first-hand:
  • A Stop that stopped nothing writes no row. "The provider had already finished this turn." is gone, including for a Stop of a turn that ended by itself.
  • The one "Cancellation requested." note is keyed by the turn it stopped, so a repeated Stop rewrites it.
  • The refusal and "not confirmed" rows stay.
  • A second /compact or /clear while the first runs is refused by the existing gates, and one pressed after it ended runs again; only a same-id replay is answered from its record. The earlier repeat-answer code for /compact and /clear was removed.
  • Live QA re-run at 8867990f21d: no false row in any case, confirmed from the journal.
• New capability agent-session.repeated-stop.v1. Against a host without it, the desktop and phone still join a second Stop to one on its way (temporary; follow-up listed in the body).

Live QA on a second Mac with real Claude, #23935 against this PR. Two Stops of the same turn under separate ids, at once and 1.5 s apart: before, a false "The provider had already finished this turn."; after, one "Cancellation requested.". That was confirmed from both arms' journals. The desktop's own double-clicked Stop is unchanged, with one row. Screenshots are in Visual Proof.

Phone QA is BLOCKED: the emulator QA skill it needs can only be started by a person, so the phone checks were not run live. The 68 mobile tests cover them; the reason and the checks left are listed in the body.

Test flake seen, not caused by this PR: structured-agent-session-claude-compact-stop.test.ts failed once when run alongside 20 other files, then passed 3 of 3 on its own and in a second run of all 21. It tests /compact's own Stop path, which this PR does not change.

[greptile-apps]

Confidence Score: 3/5

[Medium risk] Refactors chat action deduplication and retry logic.

The PR does not appear safe to merge while the two previously reported chat-response errors remain.

Findings

1.  Changed answer falsely accepted ▶
2.  Failed Stop replaces confirmed note ▶

Summary

This PR gives each structured-chat action press a fresh operation ID and answers harmless repeats from host state rather than a client-retained ID.

• Updates desktop and mobile Stop and command handling, host prompt and Stop responses, and repeat-press coverage.
• Two earlier findings remain outstanding; neither is reposted here.

Diagram

sequenceDiagram
  participant User
  participant Client
  participant Host
  participant Journal
  User->>Client: Press chat action
  Client->>Host: Mutation with fresh operation ID
  Host->>Journal: Check current action state
  Journal-->>Host: Pending or settled state
  Host-->>Client: Apply action or answer harmless repeat

Loading

_{Reviews (5) · Last reviewed commit: "Merge PR 1 (#23935) into PR 2"}

[greptile-apps]

Changed answer falsely accepted

If a single-question prompt accepts free text and the first reply is lost, the user can submit an answer that differs only in surrounding whitespace. The recorded choice ID trims that whitespace, so this comparison returns success without sending the second answer to the provider. The user is told the new answer was accepted even though the provider received only the first one.

Knowledge Base Used: Agent workspaces and sessions

[pullfrog]

Important

The repeated-Stop guarantee has a gap for command turns: a second Stop of a running /compact turn can still append a second "Cancellation requested." row, because the fallback at structured-agent-session-turns-cancel.ts:146-150 overwrites the note that answeredBefore had nulled. Detail inline.

Reviewed changes

• Fresh operation id per press. The desktop mutate hook and the mobile mutate/Stop/composer-command paths now mint a new client operation id on every press; the per-payload id map, mobile id-retention helper, structured-agent-session-operation-identity.*, and isUnconfirmedConversationCommand are deleted.
• Host answers harmless repeats from recorded state. A re-answered prompt returns its held resolution (resolvedWithSameChoice); a Cancel of an already-cancelled prompt answers quietly; a /clear re-pressed by the same caller on a tab-less source short-circuits to the committed record before admission (committedClearOfCaller); a repeated Stop of a turn an earlier Stop answered for is suppressed by reading that Stop's note off the named turn (structuredAgentSessionNamedTurnStop).
• New capability agent-session.repeated-stop.v1 plus a transitional client-side in-flight Stop join used only against hosts that lack it.

The /clear short-circuit was checked: context.openConversation is journal-only and starts no agent, and the tabId === null guard only ever returns the same already-committed fact. No other concerns.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

Important

A repeated /compact press can be answered with a false completed when the command turn it joins was already stopped but has not ended yet. Detail inline.

Reviewed changes

• Changed the conversation-command in-flight join key to [callerKey, command], so a same-caller repeated /clear waits behind the first and is answered by it instead of being refused conversationCommandInFlight.
• Added repeatedStructuredCompaction, which joins a /compact press to the caller's last accepted /compact while that one waits, runs, or compacted with nothing newer, read from the journal.
• Added host tests for the /clear double press and the repeated /compact (including a relaunched host), plus a tab-table test for a /clear answered after commit.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[greptile-apps]

Failed Stop replaces confirmed note

When a Stop succeeds, it writes “Cancellation requested.” If a later Stop of the same turn encounters an adapter error, this turn-keyed write replaces that confirmed note with “Cancellation was not confirmed.” The chat then shows a failure in place of the successful cancellation.

Knowledge Base Used: Agent workspaces and sessions

[pullfrog]

ℹ️ No critical issues — one test-coverage suggestion inline.

Reviewed changes

Reviewed the three commits pushed since the prior pullfrog review (f5e0acee4c, 7e950635fd, 8867990f21); the rest of the PR was covered in earlier runs.

• Reverted the /compact repeat join. f5e0acee4c reverts 25541b7fc0: the conversation-command in-flight key returns to [callerKey, clientOperationId], structured-conversation-compaction-repeat.* is deleted, and a /compact//clear pressed again while one runs is refused by the existing gates rather than joined. This removes the previously open risk where a stopped-but-still-running compaction could be answered with a false completed.
• Stop notes keyed by the turn they stopped. 7e950635fd drops STOP_NOTE_ALREADY_FINISHED and structuredAgentSessionNamedTurnStop, and keys structuredAgentSessionStopNoteIdentity by turnId ?? liveTurnId ?? clientOperationId. A Stop that cancelled nothing writes no row, and a second Stop of a running compact: turn rewrites the one turn-keyed row instead of appending a second — closing the command-turn duplicate reported in the prior review.
• Capability comments. 8867990f21 updates agent-session.repeated-stop.v1's comments to the new meaning (comment-only).

I re-ran the touched host suites (92 tests across 10 files) plus pnpm tc:node; all pass, and no stale references to the removed symbols remain.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

The prior review's command-turn finding was fixed by keying the note on the turn, but this case only covers a normal turn-1. A command turn takes the runningCommand override that force-rewrites note to Cancellation requested. after stopChild, so a second named Stop of a live compact: turn is the exact path that used to append a duplicate row — and no test here asserts its row count. Consider a command-turn variant (two named Stops of a running compact: turn, expecting one row) so that path stays pinned.

[greptile-apps]

Comments Outside Diff

These findings could not be posted inline.

•  Old failure hides new error src/renderer/src/components/native-chat/structured-conversation-command-send.ts:51 ▶

  If a later /compact fails to start with the same failure fact as an earlier start, this check can mistake the old row for the new command’s row. If the reply arrives before the new row is loaded, it returns no command error. The new row may appear later, but the user gets no immediate feedback that this press failed. Match the row to this start, not just to the failure fact.

[pullfrog]

ℹ️ No critical issues — minor suggestions inline.

Reviewed changes

Reviewed the five commits pushed since the prior pullfrog review (37bc02032e, 4380ad85a9, 13a6333cd6, 65bde90440, 3e11a8f5e3); the two merges and 4380ad85a9 are mechanical.

• Captured the press-time fence for a named Stop. write now reads stateRef.current.fence before it awaits the quiet-repeated-Stop capability and threads it into send, so a Stop can no longer go out against a runtime the pane replaced while that probe was in flight (65bde90440).
• Covered both host capabilities in the fence-move test. The command-start-failure test now asserts the drop for hosts with and without agent-session.repeated-stop.v1; removing the explicit pressed fence makes both cases fail (3e11a8f5e3, 4380ad85a9).
• Merged the base branch. Adapted test call sites to the base's two-argument host.close; no behavior change.

ℹ️ Nitpicks

• send's default pressedFence = stateRef.current.fence is now unreachable — both call sites pass it — and would silently reintroduce the late read if a future caller omits the argument. Removing the default makes the invariant compiler-enforced.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

This reads the fence inside write, so it is captured before write's own capability probe — but cancel in use-structured-agent-session.ts:263 awaits supportsStructuredAgentSessionPromptCancel before it calls mutate, so for a Stop that names a prompt the fence is still read after that await and the Stop can still be retargeted at a runtime the pane replaced. The new comment ("read before any await, so a write never retargets") is broader than what this covers; either capture the fence at the caller, move the probe, or narrow the comment to the await it actually guards.

Technical details

# `pressedFence` only covers `write`'s capability await, not the caller's

## Affected sites
- `src/renderer/src/components/native-chat/use-structured-agent-session-mutate.ts:162` — `pressedFence` is read here, one layer below the caller that awaited.
- `src/renderer/src/components/native-chat/use-structured-agent-session.ts:262-267` — `cancel` awaits `supportsStructuredAgentSessionPromptCancel(target)` before `mutate('agentSession.cancel', ...)`; a Stop from the prompt/approval Stop button takes this path (`NativeChatStructuredSession.tsx:181`).
- `src/renderer/src/components/native-chat/use-structured-agent-session.ts:280` — `respond` awaits the question-answers probe before `mutate`; same shape for a free-form answer.

## Why it still retargets
1. `cancel(turnId, prompt)` reads `stateRef.current.fence` only after `await supports...` (which is a status round trip on a remote/paired host).
2. If the fence moved during that probe, `write` captures the *new* fence, so `send`'s `targetFence` equals the current fence and `settlesHere()` keeps the result.
3. The envelope's `expectedRuntimeFence` matches the new runtime, so the host accepts and runs the Stop against a runtime the pane replaced.

## Required outcome
- A capability probe awaited before a mutation must not be able to move the fence the mutation is sent with.

## Suggested approach (optional)
- Capture `const pressedFence = stateRef.current.fence` at the top of `cancel`/`respond` and, after the probe, drop when `stateRef.current.fence !== pressedFence`; or plumb an explicit pressed fence through `WriteArgs`. Removing the now-dead default on `send` would force callers to be explicit.