[alfredolopez80]

Fixes #1409. Refs #1410.

Review rounds 1 to 3 and a closing audit are done; their findings are fixed in the commits below. T2 has not run on the final head; see "Not verified".

Why

The Desktop composer could stay blocked on "Checking agent access for this team…" with no way out. The team id is being retired (#334, then #594, then #1222). This PR stops team-id mechanics from affecting normal use. With the gate gone, a send the server rejects became the path a user meets, so this PR also stops such a send from losing the user's input.

What changes, one commit per root cause

Commit	Root cause	Change
fix(desktop-app): build the access catalog for one committed session	Main read the committed session with no owner while a team hop or switch replaced it in steps, and published the result with no check	Read the session under the native commit owner, build outside it, re-check and publish under it. Nothing else waits for a build
fix(desktop-app): remove the composer's team catalog gate	The composer refused to send unless the cached catalog's team id matched the session; two states had no exit	Gate, notices, retry button and resolver removed. The server authorizes each send. Undoes R7-L1 (02341fd84, 10803b41a) and follow-ups 8244067e0, 25f5da7a3 from #1084
fix(desktop-app): keep the selected agent when the catalog does not list it	The current team's catalog decided which agent could stay selected	The catalog no longer deselects. A selection ends in one of these cases: • the server denies the agent, on a read, a rename, a running task's status check, or a send it answers as a loss of access; • the user selects something else; • the session identity changes; • a restored workspace snapshot replaces it. Replaces the selection rule of 36e4d9ef2
fix(desktop-app): show the workspace for a selected agent when the catalog is empty	ChatPage and AgentsPage showed no workspace for a selected agent with an empty catalog	A selected agent gets the workspace
test(desktop-app): remount the composer by navigating in the focus test	An existing focus test emptied the catalog to unmount the composer, which the previous commit stops	The test goes to Files and back. Assertions unchanged
feat(desktop-app): remove unanswered local turns from the chat store	The store could not take back a turn the server never accepted	removeMessages in the chat store, limited to local user turns with no stored sign of a server answer, with its IPC channel
fix(desktop-app): return a rejected send to the composer	A send the server rejected returned after the composer was cleared and the turn was written, and a 401 was treated as a doubt about the agent	The text and attachments go back to the composer, the turn is withdrawn, and only a reported loss of access holds the agent
fix(desktop-app): show the failure sentence for a send kept behind Recover input	The composer alert fell back to the raw IPC error for a failed send once the send-time error was cleared	The alert shows the sentence for the failure's kind; the raw error stays under Technical details. The access hint no longer mentions a team
fix(desktop-app): keep a held send that was posted and failed without a rejection	While another path held the agent, any error withdrew the turn, including after the Host may have accepted it	A held send that never reached the main process, or was answered with a 401 or 403, is withdrawn; a send handed to the main process that failed in another way keeps its turn
fix(desktop-app): release a send's activity entry on every exit	Some exits of a send left the agent's activity stream open	One finally releases the send's activity entry unless a started task took it over

These commits change no behaviour:

• a catalog test for a team hop from a session with no team;
• a selection test for a held agent restored from a workspace snapshot;
• a test comment and a code comment;
• synthetic test tokens for the public boundary scanner;
• a simplification of the rejected-send path, which removes a toast that could not fire;
• tests for its attachment guards;
• tests for the guards of the rejected-send path and for the tombstone and sender checks of chat:removeMessages;
• a refactor that shares the durable write of a kept turn;
• comments on what the removal rule, a withdrawal, each send failure reason and the "handed to the main process" flag cover;
• tests that pin the activity release on a generic failure and on a synchronous reply, and a logout test whose witness now observes the logout;
• descriptive test titles in place of review ids;
• a store test that pins both orders of a removal and a reconcile replace on one chat: a withdrawn turn is not written back.

The branch also merges dev up to e611ebfcb (no conflicts).

Behaviour changes to review

• A catalog request can now reject where it used to resolve with a catalog of a session that no longer existed.
  • It rejects with stale_auth_epoch when the user logged out or changed during its build, or when the session changed twice.
  • It rejects with Not authenticated when a logout lands between a discarded build and the rebuild's session read (read in the code, not run).
  • getConnectors and the plugin SDK's contexts.read capability use the same entry and inherit these rejections. The SDK's mcp.read capability uses the same entry, but its existing catch turns any catalog failure into an empty agent list, so it does not surface them.
  • A build overtaken by the same user's session change is discarded and rebuilt once.
• An agent removed on the server stays selected until the server denies it: on a read, on a rename, on the status check of a running task, or on a send answered with host_access_revoked or with a 403 whose follow-up read is also denied. A send rejected in any other way (a 401, or a 403 whose follow-up read is not denied) keeps the agent selected.
• A rejected send no longer loses the input.
  • When the composer can take the input back, the text and attachments return to it with no message. The rejected turn is removed from the transcript, and the user can send again.
  • Otherwise the input waits behind Recover input, and the composer shows the text for that kind of failure. Under Technical details it shows the raw error, or, for a send the hold stopped before it reached the main process, "The agent was on hold, so the message was not sent." For a rejection or a loss of access the text is: "Access issue while sending to this agent. You may not have access to this agent anymore. Sign in again or ask an admin for access." This happens when the composer changed while the send was pending, when the send was a Retry that carried attachments or met a draft, and when a send with attachments ended while the agent was held.
  • A 403 whose follow-up read is not denied (it succeeds, or fails with a network or server error) used to show an error and Recover input; it now behaves as any other generic rejection.
  • A rejection that persists returns the text on every send, with no message.
• When the server reports that access to the agent is lost, the agent is held as before, with no notice at that moment.
  • A send with text only finds its text in the composer when the agent is selectable again.
  • A send with attachments is offered back by Recover input, text and attachments together, under the access sentence, when the agent is selectable again.
  • Desktop: a send refused with an authorization error ends silently and the typed message is not recoverable #1410 stays open for the missing notice.
• A send that fails for another reason (network, 5xx, 404, 413, 422) keeps its error, toast, Retry and Recover input while the agent is selectable. One thing changes: the alert keeps its sentence after the user types, attaches something or returns to the chat. It used to turn into the raw error then. The raw error stays under Technical details.
• The hint shown for an access failure no longer mentions a team. It read "Authentication/permission issue. Re-authenticate or switch team/access scope." and now reads "You may not have access to this agent anymore. Sign in again or ask an admin for access." No other send-failure text mentioned a team.
• If another path holds the agent while a send is pending:
  • A send that never reached the main process, or that the server answers with a 401 or 403, is handled as a loss of access, and its turn is withdrawn.
    • A text-only send returns its text to the draft, or waits behind Recover input when a newer draft is there.
    • A send with attachments waits behind Recover input with its text. It shows the sentence for the kind of failure that ended it: the access sentence when the hold stopped it or the server rejected it, and the connection sentence when the network failed before the send reached the main process.
  • A send handed to the main process that fails in another way keeps its turn, as before. This includes a refusal inside the main process before the HTTP request (request validation, minting the RPC token). Its input, which used to be unreachable, is offered by Recover input and Retry when the agent is selectable again.
• Every exit of a send now releases its entry in the agent's activity stream unless a started task took it over. This closes the stream when the chat was deleted, the agent was held, or the session scope changed while the send was pending.
• The catalog's build does not hold the commit owner, so sends, team switches and logouts do not wait for a build. The session read before the build, and the publish after it, wait for the current holder of the commit owner. That read can call getMe (only when no user is cached) and bind the chat store, so a logout can wait for it.
• The composer shows no access notice. While catalog data is retained, a failed catalog refresh shows no error on the Chat and Agents pages. The Members tab of an agent with no members to show still prints the refresh error, which can be a raw stale_auth_epoch message. That display predates this PR.
• With an agent selected, a catalog failure with no retained data is not shown on the Chat or Agents page: both pages render the workspace for a selected agent.

Validation (Node 24.22.1)

Check	Result
scripts/minikube/t0.sh at the head 18691a395, which runs the desktop-app tests	T0_EXIT=0, T0_AFFECTED_CHECKS=PASS, 477 files, 5878 tests. A first run on a saturated host timed out in App.gfsColdStart.r15.test.tsx, a dev file this PR does not touch; that file passes 21/21 on its own, and the rerun passed
Removal and replace ordering on one chat	Both orders leave the withdrawn turn removed. Without the queue around removeMessages, the new test and the upsert ordering test turn red
tsc main and UI, prettier on the touched files, style-rules, public boundary scanner, at c3fa9a974	Green; style-rules has 1 warning in a file this PR does not touch
Fail-before on d02fcb9f1, access catalog tests	12 failed, 4 passed (the 4 pin behaviour that must not change)
Fail-before on d02fcb9f1, selection and page tests	13 failed, 6 passed
18 mutations of the round-1 production changes, one at a time	Each turned red every test the plan named, at f7318e80c
Mutations of the round-2 changes	Each turned its named tests red at d01c1db4e. One mutation could not fail, because the check it removed had no observable effect; the check was removed instead
Mutations of the round-3 changes, at the commit that adds their tests	Each turned its named tests red. Only the one that moves the "task took over the activity entry" flag earlier survives: no statement between its two positions can throw, so the move cannot be observed. Removing the finally release now turns 7 tests red
Round 2's reviewed head (d01c1db4e): its tests on the code at 331141614	306 passed, 2 failed. Both are intended changes: a held send handed to the main process that failed on the network now keeps its turn, and the alert keeps its sentence after the send-time error is cleared
Commits 5 and 6 of round 3 reverted alone in a scratch clone	Each applies without conflict, and the touched renderer tests pass
Manual run of this branch's Desktop build against production	Signed in, Settings → Information shows the production endpoints with health OK
CI on 18691a395	63 checks passed

Not verified

• T2 has not run on the final head. A T2 run on cd16755b6 stopped in T1 on one control-api test: 1054 of 1055 passed. That test races its own COMMIT (control-api: passwordResetLostCommit real-Postgres test reads before the COMMIT is applied #1442) and this PR does not touch control-api. The rerun was refused because dev had moved.
• No Playwright run has been done.
• The catalog fix relies on the server accepting a token after a later team switch issued another one. This was read in the server code at d02fcb9f1 and 27776e8, not executed against a server. Remove Team Token PR2: Runtime actions use validated access paths #594 changes the session model, so the premise must be re-read when it merges.
• The trigger in the original report was not identified. The race is the mechanism that best explains it.
• How often each accepted edge case of the rejected-send change occurs is not measured on the client. On the server, control-api logged one rpc_host_access_denied in 30 days on clerum-dev (host_missing) and none on clerum, against 254 and 599 sends.

Known limits

• 46 other AppService methods (43 public, 3 private) call requireSessionToken() outside the commit owner, counted on the syntax tree of desktop-app/src/appService.ts at d01c1db4e. They are out of scope here.
• The doc comment of sandboxUiSessionEpoch in appService.ts says a hop bumps sessionGeneration. The code does not, and this PR does not edit that comment.
• An agent that another team grants can still be held as uncertain while the team directory cache is empty or does not list it.
  • The RPC token is then minted in the current team. The server answers 403 to the read, or to the send and its follow-up read, and the agent is deselected.
  • Selecting it again re-checks it, and a team switch clears the hold.
  • This PR does not change that case, except that a send no longer loses its text in it. A 401 on a send no longer holds the agent.
  • Owner: Remove Team Token PR2: Runtime actions use validated access paths #594 / Task 106: fix before activating the access catalog or V2 session issuance #1222. host access: return a machine-readable revocation code on the RPC token mint 403 #941 would let Desktop tell this case from a real loss of access.
• Follow-ups found in review and left out of this PR:
  • Desktop: a message the Host accepted is reported as failed when the local chat write throws #1435: a message the Host accepted is reported as failed when the local chat write throws.
  • Desktop: classifyErrorKind labels any message containing "401" or "403" as an access failure #1436: classifyErrorKind labels any message containing "401" or "403" as an access failure.
  • control-api: passwordResetLostCommit real-Postgres test reads before the COMMIT is applied #1442: the flaky real-Postgres control-api test seen in T2.
  • Desktop: a send refused with an authorization error ends silently and the typed message is not recoverable #1410: three more items, listed in a comment there:
    • the silent generic rejection;
    • retained attachments dropped by a team switch;
    • the access sentence shown once access is back.

🤖 Generated with Claude Code

[Mircala]

Evenfire Reviewer — Round 1

Reviewed head: cd16755b6812bde37ef3be36d3109ac354a2327e

Decision: Approve with follow-ups

The composer no longer blocks on a team-stamped catalog, a catalog built across a team hop or a team switch is published only for the session it belongs to, and a send the server rejects returns its input instead of losing it. I found no merge-blocking defect. Two statements in the description do not match the head, and T2 has not been run.

Must fix

No must-fix items found.

Verified

• The catalog is read and published under the native commit owner, built outside it, and rejected with stale_auth_epoch when the session changed; the token is correctly not compared, because a hop mints a new token without advancing the generation and the previous token stays valid.
• chat:removeMessages checks the sender, bounds the ids, and the store removes only an unanswered local user turn; a reconcile that read the transcript before the withdrawal cannot write the turn back.
• A held send is withdrawn only when it was never posted or the server answered 401 or 403; a posted send that failed any other way keeps its turn. One finally releases the activity entry unless a started task took it over.

Validation gaps

• Previous-head regression proof: not verified in this environment.
• No T2, Playwright, or live Desktop run was performed. The description already schedules T2 on this head. dev has moved since the merge (mergeable_state: behind), so rebase or merge before that run.

PR description

Update required. R1-L1 — the sandboxUiSessionEpoch comment does not claim that a hop bumps sessionGeneration; it says the opposite, and the PR does not touch it. The opening line also still says the PR is a draft.

Pre-existing

Pre-existing: none identified during the scoped review.

Next action

Run T2 once on this head, and correct the two statements in the description.

useAgentChatController.ts already has four fix: commits in this PR. Another correction there should come with a decision table for the send exits, not another local patch.

Full review archive: pr-reviews/pr-1425/r1-26-11-11.md

— Review performed by Evenfire Reviewer

[alfredolopez80]

@claude Please run a closing review and audit of this PR at head fc4cef0ca.

Scope. Review the desktop-app/ changes against dev: git diff origin/dev...fc4cef0ca -- desktop-app. The merges of dev into this branch bring no change of their own; do not review the code they bring in. Read the PR body first. It lists every intended behaviour change, and anything that differs from it is a finding.

1. Access catalog (desktop-app/src/appService.ts, refreshAccessCatalog)

• The session is read under withNativeAuthEnvironmentCommit, the catalog is built outside it, then it is re-checked and published under it. At most 2 builds.
  • Confirm that no path publishes a catalog built for a different user, team or sessionGeneration.
  • Confirm that a logout or user change during the build rejects with stale_auth_epoch.
  • Confirm that a same-user session change discards the build and rebuilds once.
• Look for deadlocks: can any caller already holding the commit owner reach refreshAccessCatalog, directly or through getConnectors, access:refreshCatalog/access:getCatalog, or the plugin SDK contexts.read/mcp.read?
• Check what each caller does with the new rejections. The PR body states that mcp.read swallows them.

2. Composer gate removal and agent selection (ComposerPanel.tsx, useAppController.ts, ChatPage.tsx, AgentsPage.tsx)

• Confirm that nothing still blocks sending on the team catalog. Search for leftovers of the removed gate, resolver and notices: agentCatalogAvailability, accessCatalogScopeRef, "Checking agent access".
• The selection effect now only deselects an agent the server holds. Check every way a selection can end (listed in the body). Look for a stale selection after logout, a user change or a workspace snapshot restore.
• With a selected agent and an empty or failed catalog, both pages render the workspace. Check that nothing crashes or renders against a missing agent record.

3. Rejected send (desktop-app/ui/src/hooks/domain/useAgentChatController.ts, sendAgentMessage and helpers)

Trace every return and every throw site of the send try, and for each exit check the following:

• No input is lost. Text and attachments either go back to the composer or the draft of the send's own chat, or stay behind Recover input.
• Correct target. The input lands in the right chat, agent and composer, including after the user switched chat, agent or tab while the POST was pending.
• No duplicate send on the Host, except an explicit Retry.
• No turn comes back. A withdrawn turn is never written back by hydrate, older-page loads or backfill. Check the withdrawnTurnIdsRef fence and the re-filter after the createChat await.
• Held agent. Classify each outcome as before the handoff to main, after it, 401/403, or another error. Check postIssued: it is set right before invokeHostMessage. Is that the right point, and can a hold land between the check and the call?
• Activity entry. The finally must release the send's entry exactly when no started task took it over (activityHandedToTask). Look for a leaked stream, a double release, or a stale release that closes a newer scope's stream.
• Scope changes. Check logout, team switch and user change during each await. Nothing from the old session may be written into the new session's stores (draft, chat store, retained send).
• Texts. Check describeSendFailure/errorRecoveryHint in ui/src/lib/format.ts and the composer alert:
  • the alert never shows a raw IPC error;
  • the sentence matches the recorded kind;
  • no user-facing text mentions a team.

4. chat:removeMessages (desktop-app/src/chatStore.ts, ipc.ts, preload.ts, renderer.d.ts, ui/src/hooks/useChatStore.ts)

• The IPC handler runs assertTrustedSender first. Check that the sanitizer enforces 1–16 ids of at most 128 characters and rejects path traversal.
• The store may remove only local user turns that carry no stored sign of a server answer: no task_id, no assistant or server turn, not answered synchronously, no legacy answer. Removal must be all-or-nothing per chat, must not create a chat, and must be serialized with upsert and replace.
• A deleted or missing chat returns 0.
• Could a compromised renderer use this channel to delete data that it could not already delete through chat:upsertMessages/chat:replaceMessages?

5. Regressions against dev

For each changed unit, compare the behaviour on dev with the head. Every changed behaviour must match a statement in the PR body. Report any unexplained change, any broken caller anywhere in the repository (plugin SDK, other UIs, e2e or Playwright specs, docs), and any code left without a caller by the removals.

6. Tests

• Do the new and rewritten tests check real behaviour rather than mocks?
• Does every negative assertion (not.toHaveBeenCalled, "nothing was written") have a positive witness in the same test proving the code path ran?
• Is there test-only production code, a fixed sleep that could hide a race, or a test that would still pass with the feature removed?
• Name the changed behaviour that has no test that would fail if it broke.

7. Text and repository rules

• Code comments, docstrings, .d.ts files, test titles and the PR body must be true against the code at fc4cef0ca.
• Check the CLAUDE.md/AGENTS.md rules: logging standard, shared capability naming (no team-id, agent or vendor names), no swallowed errors or unrequested fallbacks introduced by this PR.

Reporting

List findings by severity (High / Medium / Low). Each finding needs:

• file:line at fc4cef0ca;
• a concrete scenario;
• whether this PR introduced it or it already existed on dev.

State explicitly what you verified as clean.

Known and out of scope: #1435, #1436, #1442, and the three #1410 items in its comment (silent generic rejection, retained attachments dropped by a team switch, the access sentence once access is back).

[claude]

Claude finished @alfredolopez80's task in 9m 26s —— View job

---

Closing review & audit — head fc4cef0ca (diff vs origin/dev e611ebfcb)

Decision: Approve. I traced the desktop-app/ diff against dev for all seven audit sections. No High or Medium defect found. Every behaviour change I could reach matches the PR body. The findings below are Low and non-blocking; three are introduced-but-benign, one is a pre-existing comment (correctly disclosed in the PR body).

• §1 Access catalog · [x] §2 Gate removal & selection · [x] §3 Rejected send · [x] §4 chat:removeMessages · [x] §5 Regressions · [x] §6 Tests · [x] §7 Text & rules

---

Verified clean

§1 Access catalog (appService.ts:4335 refreshAccessCatalog)

• Session read, build, re-check, publish are three correctly ordered steps; the build runs outside the commit owner and at most twice.
• Publish is guarded by me.id (logout/user change → stale_auth_epoch), then sessionGeneration and teamId (same-user switch → discard + one rebuild). No path publishes a catalog for a different user/team/generation.
• I confirmed the token is correctly not compared: a transient runWithTeamContext hop calls switchSessionToTeam(..., { advanceSessionGeneration: false }) for both the switch-in and the restore (appService.ts:1437,1450), and commitSessionToken only bumps when advanceSessionGeneration !== false (appService.ts:1219). So a hop does not advance the generation, and the hop's whole switch→operation→restore runs inside one withNativeAuthEnvironmentCommit (appService.ts:1423), so the publish check can never observe a mid-hop team. The fix is sound.
• No deadlock. All entrypoints (access:getCatalog/access:refreshCatalog at ipc.ts:1374/1378, getConnectors at ipc.ts:1717, the SDK contexts.read/mcp.read) call the service outside any commit block; bindCurrentChatStore does not re-enter the queue.
• Rejection handling matches the body: contexts.read (pluginSdkCapabilities.ts:256) propagates; mcp.read swallows via .catch(() => null) (:284).

§2 Gate removal & selection — The team gate is gone with zero leftovers repo-wide (agentCatalogAvailability, accessCatalogScopeRef, selectedAgentSendBlocked, composer-agent-catalog-notice, "Checking agent access" all return nothing; the module and its tests are deleted). The selection effect (useAppController.ts:690) now only clears a held agent; the early !auth.isAuthenticated return matches dev, so logout clearing is unchanged, not regressed. AgentsPage/ChatPage render the workspace for a selected agent with an empty catalog, and AgentWorkspace tolerates an agent missing from the catalog (agentDisplayByName[selectedAgent] ?? selectedAgent, connectorActionsByName → undefined).

§3 Rejected send — I traced every exit of the send try:

• No input loss: each undelivered exit routes through returnUndeliveredSend (composer when draft free + attachments returnable, else retained snapshot) or keepUndeliveredTurn.
• Correct target / no cross-session write: returnUndeliveredSend is only reached under sendAuthScopeIsCurrent(); attachments return only when sendChatIsVisible() and the attachment revision is unchanged; draft text is written to the send's own sendChatId.
• postIssued = true sits immediately before invokeHostMessage with no intervening await, so a hold cannot land between the flag and the call. 401/403/pre-post → withdraw; handed-to-main non-auth → keep. Matches the body exactly.
• withdrawnTurnIdsRef fence is applied at the server backfill (:1726), hydrate (:2264) and the re-filter after the createChat await (:2292).
• Texts: describeSendFailure never returns the raw IPC error (only fixed sentences / kind-selected copy); the auth hint no longer mentions a team.

§4 chat:removeMessages — assertTrustedSender first; sanitizeChatMessageIds enforces 1–16 trimmed non-blank ids ≤128 chars. (Ids are only matched against stored message.id via a Set, never used as filesystem paths, so traversal is a non-issue; agentRef/chatId keep the same sanitizeString protection as the sibling handlers.) The store rule is all-or-nothing, serialized via serializeChat, does not create a deleted/missing chat (returns 0), and removes strictly less than replaceMessages already can — so no new capability for a compromised renderer.

§5 / §6 / §7 — No orphaned consumers of the deleted module. Test fixtures delegate removeMessages to a real in-memory store (mockClerum.ts:141), so the withdraw path is exercised for real; the body's mutation-testing evidence is strong. The sandboxUiSessionEpoch/comment caveats and the auth-hint change are true against the head.

---

Findings (all Low)

L1 — pre-existing, disclosed. appService.ts:1553-1555: the sandboxUiSessionEpoch doc comment states "every token commit bumps it, including the two of each transient team hop." Per §1 above, a hop passes advanceSessionGeneration: false, so those two commits do not bump sessionGeneration; the comment is stale. Not introduced here (the PR doesn't touch it) and accurately captured in the body's Known limits. One note for the record: the comment text does assert the hop bumps the generation, so round‑1's "it says the opposite" reading doesn't match the source — the body's current wording is the correct one.

L2 — introduced, benign. useAgentChatController.ts:3789 + :4244: on every withdraw exit, withdrawUndeliveredTurn calls releaseSendActivity() and the finally calls it again (activityHandedToTask is only set on the success-task path at :4163). The second call is idempotent (id-filter then maybeStopAgentActivityStream on an already-empty list), so it is harmless, but the double call is not obvious — worth a one-line comment that the finally release is intentionally idempotent with the withdraw path. Fix this →

L3 — introduced, edge, no data loss. In the auth and held-by-another-path exits, returnUndeliveredSend runs before await withdrawUndeliveredTurn(). If the store refuses the removal (removeMessages throws), the optimistic turn stays visible marked error while the same text is already back in the composer/snapshot — a transient duplicate, surfaced by the WITHDRAW_REJECTED_TURN_FAILED_MESSAGE toast. Only reachable if the store refuses to remove an unanswered local turn, which the removal rule should never do for a rejected send. Acceptable; noting for completeness.

L4 — nit. useAgentChatController.ts:1698: the local older-page merge (mergeUniqueMessages(chatMessagesRef.current, unseenLocal, …)) is the one merge site that does not apply the withdrawnTurnIdsRef fence. Harmless in practice — removeMessages deletes the turn from the store and a just-sent turn is inside the loaded window, not an older page — but it's the lone unfenced path if you want symmetry.

L5 — test nit. useAppController.rejectedSend.test.tsx:968: a fixed setTimeout(resolve, 100) in the "task keeps the stream open (control)" test. It asserts persistence (the safe direction) and has a positive witness at :967, so it won't produce a false green, but a fixed sleep is a minor smell.

---

Validation gaps (from the body, unchanged)

• T2 has not run on fc4cef0ca. The last attempt stopped in T1 on the unrelated flaky control-api test (control-api: passwordResetLostCommit real-Postgres test reads before the COMMIT is applied #1442); this PR touches no control-api file. A clean T2 on the final head is still owed.
• No Playwright run.
• The server-accepts-post-hop-token premise is read, not executed (re-verify when Remove Team Token PR2: Runtime actions use validated access paths #594 lands).

Out of scope as stated: #1435, #1436, #1442, and the three #1410 items. The opening line of the PR description still says "Draft." — flip it when you promote the PR.
· branch fix/1409-composer-gate-and-catalog-hop-isolation

[jozer-rami]

Approving at fc4cef0ca.

Verified

• The catalog is read and published for one committed session. A team hop holds the commit owner from switch to restore, and the publish re-checks user, generation and team. No deadlock path.
• The server authorizes every send. The RPC token mint checks team membership and the host grant, and rpc-proxy runs the host-access check on each request. Removing the composer gate opens no authorization gap.
• chat:removeMessages adds no capability beyond the existing chat handlers.
• The withdrawn-turn filter covers every write to the store.
• The touched test files pass locally on Node 24.22.1: 586 of 586. I ran 34 mutations of the production changes, and the tests caught every one.

Non-blocking follow-ups

1. Silent rejection (#1410). A 401, or a 403 whose follow-up read is allowed, returns the text to the composer with no message (useAgentChatController.ts:4166-4199). On an expired session this lasts until the entity-change stream ends the session. Showing the access sentence while still returning the input would close it.
2. External logout. onExternalSessionEnded (useAppController.ts:183-190) resets navigation but not the data controllers. ChatPage (ChatPage.tsx:20-28) can then auto-select the previous user's agent from the cached catalog for the next user. The selection stays until the first denied read, and only the agent name is exposed. The stale cache predates this PR. This PR removes the same-team deselect and the send gate that used to cover it. The body lists "the session identity changes" as ending a selection, which this case does not meet.
3. Empty chat after a rejected first send. When a new chat's first send is rejected, an empty local chat stays in the sidebar, titled with the withdrawn text. The index keeps messageCount: 1.
4. Refused withdrawal (rare). If an earlier task's late reply from durable recovery (useAgentChatController.ts:2855-2888) is stored after the optimistic turn, removeMessages refuses (chatStore.ts:2266-2276). The text is already back in the composer, so the turn shows twice. Ignoring a later assistant message whose task_id belongs to another stored user turn would fix it.
5. PR body. The Connectors page (McpServersPage.tsx:165-166) can also show the raw stale_auth_epoch text, not only the Members tab. The opening line still says "Draft."

T2 on the final head is still owed, as the body says.