Repository navigation
Cloud: Share with Me resends the refused start - #29785
Conversation
After Share with Me went through, the card only retried the switch. The refusal had already handed the prompt back to the composer, and a chat on another machine starts only with a send, so nothing happened until the person sent again. The share now retries and resends the composer's prompt, as Trust's answer does. Retry after Ask the Owner does the same once the owner has shared; with no share yet it stays a plain retry. Fixes #29563 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3bab30503f0b9a7059e5
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Gallery before/after for
States
Pick other states with a Shipped in:
|
|
Owned by an agent session · session |
|
Review (independent Codex gpt-6.1-sol, high, via the review router; full diff from merge base b06e339 to this head): SHIP at 53922f6. [P2] [follow-up] [App.tsx:11757] - The delayed share callback sends whatever is currently in the composer without verifying that the original refusal/session is still active. If the user navigates or edits/types while sharing is in flight, it can submit an unrelated draft (and attachments) to the wrong chat. Capture and validate the refusal/session generation before retrying and sending. |
After Share with Me went through on a refused Cloud chat start, nothing happened until the person sent again (#29563, a P2 from #29283's review).
Why: the refusal hands the queued prompt back to the composer (
harnessSwitch.fail), and a chat on another machine starts only with a send (runreturns whenstartsOnSendand nothing is queued). The share'schat.harness.retryre-armed the switch with an empty queue, so it waited.Fix: a share that went through retries, then sends the composer's prompt again, the same way Trust's answer already resends (
trustAsk.refused(..., () => composerHandle.current?.send())). Retry after Ask the Owner does the same once the owner has shared; with no share yet it stays a plain retry. Without anonSharedhandler the card falls back to the old retry.Tests:
SwitchNotice.share.test.tsxchecks that a share resends, that without a handler it falls back to a retry, that a recheck which finds the share resends, and that a recheck with no share is a plain retry.Risk: low. Webview only, 4 files. It only runs after a successful share on the start-refusal card.
#29564 (the pane keeps
ownerCloud: falseafter a share) is left for its own PR: whether a guest counts as owner is a separate decision.Fixes #29563
🤖 Generated with Claude Code
Agent session: agent session
Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Fixes Share with Me on a refused Cloud chat start, where after the share went through nothing happened until the person sent again (#29563).
The refusal hands the queued prompt back to the composer, and a chat on another machine starts only with a send, so the share now retries the start and resends the composed prompt, matching how Trust's answer already resends. Retry after Ask the Owner resends once the owner has shared; with no share yet it stays a plain retry. Without an
onSharedhandler the card falls back to the old retry.Tests cover the resend on share, the fallback without a handler, a recheck that finds the share and resends, and a plain retry when a recheck finds none.
Written for commit 53922f6. Summary will update on new commits.