Accept all of Claude's pending proposals on the current document in one gesture #46
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
"Accept all" — a single gesture on the review preview that accepts every
pending Claude proposal on the current document at once, instead of clicking
✓ on each proposal one at a time.
Problem / pain
Accepting Claude's edits is currently one proposal at a time: the F10/F11
review preview surfaces each pending F4 proposal as its own
cw-proposalblockwith ✓ / ✗ buttons (
cowriting.acceptProposal→ProposalController.acceptById),and there is no way to accept them in bulk. When a writer is happy with all of
Claude's changes, they still have to hunt down and click every single ✓.
This is felt most after F11 "Ask Claude to Edit Document", where a single
whole-document rewrite is diffed into N per-hunk proposals (one per changed
span). A document-level edit a writer wants to take wholesale can produce a dozen
separate proposals, each demanding its own click — turning "yes, take Claude's
pass" into a tedious manual sweep.
Who feels it
Writers co-editing a document with Claude — especially anyone using the
document-level Ask Claude to Edit Document flow (which fans out into many
proposals), and anyone who reviews Claude's changes, decides "these are all good,"
and wants to take them in one move.
Desired outcome / value
A writer who is satisfied with Claude's proposed changes can accept them all in
one gesture, with the same end-state as accepting each individually (every
accepted span lands Claude-attributed via the seam, the baseline advances past
them, the proposals clear). Removes the per-proposal clicking tax and makes "take
Claude's whole pass" a first-class, one-click action.
Acceptance — "done right"
button) that is present when the current document has two or more pending
proposals and accepts all of them.
cowriting.acceptAllProposals) performs the samebulk-accept, so it is reachable outside the webview too.
(
acceptByIdsemantics — Claude-attributed text, baseline advance, proposalremoved); accept-all is a batched application of that path, not a new,
divergent accept mechanism.
the rest stays correct (offsets shift as each edit applies); the end document is
the same as if the writer had accepted each in a correct sequence.
can't anchor) are skipped, not force-applied, and the writer is told how many
were applied vs. left pending (consistent with the existing "undo to restore, or
reject" flagging).
that were skipped because they couldn't anchor.
(text replaced, Claude-attributed, proposals cleared), and an orphaned proposal
in the set is skipped and reported rather than mangling the document.
Scope / non-goals
document; the
cowriting.acceptAllProposalscommand + the previewheader/toolbar button; correct apply-order; orphan-skip with an applied-vs-skipped
report; reuse of the F4 accept seam.
cross-document / workspace-wide accept-all (current document only — per the
capture decision); no per-turn-scoped accept-all (the unit is the document, not
one Ask-Claude turn); no change to how individual accept/reject works; no new
proposal-granularity model.
Assumptions · constraints · dependencies
ProposalController.acceptById/listProposals, INV-9/11/12) and the F10/F11 review preview as the hostsurface; accept-all is a loop over the pending set through the same seam.
the buffer and the controller re-resolves the remaining proposals' anchors, so
bulk-accept must apply in an order (and/or re-resolve between applies) that keeps
every subsequent proposal anchored correctly. This is the main reason this is a
feature, not a bare story.
design step decides whether a confirmation is warranted (VS Code undo still
restores, as with single accept).
message to the host (like the existing ✓/✗ and F11 toolbar intents); the host
performs the accepts. No mutation in the webview.
last-span-first, or re-resolve-after-each); whether accept-all needs a
confirmation; the precise button placement/label on the preview header
vs. F11 toolbar; how the applied-vs-skipped result is surfaced (status bar /
toast / in-preview).
(#43) preview toolbar as the primary interaction surface, and #42 (Ask Claude to
Edit Document — the N-proposal source that makes accept-all most valuable).
Source / signal
Self-originated — capture session vscode-cowriting-plugin-0039 (operator ask:
"We need a way to accept all of Claude's edits").
Priority (WSJF)
Value (med–high — removes a real per-proposal clicking tax and completes the
document-edit flow from F11/#42) · Time-criticality (low) ·
Opportunity-enablement (low–med — makes whole-document editing genuinely usable) ÷
Size (small–med — reuses the F4 seam; apply-order is the only real complexity) →
favorable score.
priority/P2.Decomposition
cowriting.acceptAllProposalscommand — accept every pending proposal on the active document via the F4 seam, in a safe apply-order, skipping orphans.ProposalController(loop overlistProposalspending set with correct ordering / re-anchoring; reuseacceptById/accept).Solution notes (optional — NOT a design)
The cleanest shape reuses
ProposalController.accept/acceptByIdin a loop ratherthan a new seam: gather the pending proposals for the document, apply them in an
order that survives re-anchoring (applying later document positions first, or
re-resolving anchors after each accept), and skip any that fail to anchor —
reporting the applied-vs-skipped count. The preview "Accept all" button is a new
toolbar/header intent message (
{ type: "acceptAll" }) handled host-side, mirroringthe F11 toolbar intents and the existing ✓/✗ messages. Non-binding — the design step
settles apply-order, confirmation, and button placement.
Shipped as SLICE-3 of the document-edit flow (#51, session 0045) — completes the reach→review→accept cluster. A single Accept all gesture (toolbar button shown ≥2 pending +
cowriting.acceptAllProposalscommand) applies every pending proposal on the current doc through the existing F4 seam in descending order, skipping orphans and reporting applied-vs-skipped (INV-42). 214 unit + 73/5 host E2E green.