The claude-code provider spawns the bundled `claude` CLI via
@cline/sdk → ai-sdk-provider-claude-code → @anthropic-ai/claude-agent-sdk.
On macOS, when that subprocess is launched from inside the VS Code extension
host it performs IDE auto-connect, which shells out to `osascript`
(`tell application …`) to identify/activate the editor — raising the macOS
"control other applications" (Apple Events / Automation) permission prompt.
There is no AppleScript/osascript anywhere in the JS dependency tree (the only
match is the build-only `vite`); the Apple Event is sent by the spawned `claude`
binary, which contains 26 osascript calls. Every one is user-action-gated
(clipboard image, screenshot, terminal-setup, Claude-Desktop deep link, browser
detection) except the IDE auto-connect path, which is the only one that fires
without user action when launched inside an IDE — exactly the reported symptom
(appears on use, harmless when declined, since we never use the connection).
Fix: spawn the agent with the macOS IDE integration disabled via the provider's
`options.env` passthrough — `CLAUDE_CODE_AUTO_CONNECT_IDE=0` hard-returns out of
the binary's auto-connect gate (`mK("0") === true`), and
`CLAUDE_CODE_IDE_SKIP_AUTO_INSTALL=1` skips the extension-install deep link.
`options.env` is seeded with the full `process.env` so the default environment
inheritance is unchanged (login under HOME, proxy/CA vars preserved) — only the
two switches are added. The env flows end to end into the spawned child
(verified through the provider's getBaseProcessEnv merge and the agent SDK's
spawn). runEditTurn is the sole agent-spawn site, so this covers every flow.
Unit test asserts the agent is constructed with the two switches set and the
rest of the environment preserved. 250 unit + typecheck + build green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Surface Claude live output/progress during the asking-Claude status: notification activity line + token count, a Cowriting: Claude OutputChannel streaming assistant text, and a cancellable turn. Pure turnProgress reducer + runEditTurn onProgress/AbortSignal (vscode-free) + both call sites. INV-43..47.
Fixes#60
`tsc -p tsconfig.e2e.json` emits to `out/` but never removes outputs for test
sources absent on the current branch, so stale compiled
`out/test/e2e/suite/*.test.js` from other branches were picked up and run by the
suite glob (`**/*.test.js`) — this caused real cross-branch test confusion in
session 0048 (a deleted probe + another branch's tests ran on an unrelated branch).
Add a `clean:e2e` script (`fs.rmSync('out/test', {recursive, force})` via node, so
no shell `rm` dependency) and run it between `build` and `tsc` in `pretest:e2e`.
Cleans ONLY `out/test` — never `out/`, which holds the just-built esbuild bundle
(`out/extension.cjs`, `out/media`).
Verified: planting a stale `out/test/.../zz.test.js` then running `pretest:e2e`
removes it, and the E2E suite stays green (73 passing + 1 pending, both passes
exit 0).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
`executeCommand("undo")` is non-functional in some headless `.vscode-test`
instances (it does not restore the buffer — see #54's diagnosis), which
false-fails every undo-dependent host E2E and turns `main`'s E2E red there even
though the product code is fine.
Add a RUNTIME preflight probe (`undoCapable.ts`): edit a scratch buffer, undo,
and report whether the buffer was actually restored (memoized per run). The #38
undoMarks suite gates on it via `suiteSetup` — running normally where undo works
(full coverage preserved, real regressions still caught) and skipping with a LOUD
console warning where it doesn't (no false red, no silent loss — the skip is
logged and shows as `pending`).
This fixes the "main E2E red" symptom. The underlying headless-undo limitation is
documented in #54; #40's undo-behavior coverage runs wherever undo works.
Test-infra only — no product code changed. Verified: with undo broken locally the
#38 suite skips (1 pending) and both E2E passes exit 0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The F9/F10 author-coloring technique injects paired PUA sentinels into prose
source at span offsets, renders, then maps sentinels → cw-by-* spans. Two failure
modes when a span boundary met emphasis markup (characterized in session 0032):
- CASE1: a boundary strictly inside a delimiter run (a**b**c, between the two *)
split `**`, breaking markdown-it's delimiter pairing (stray <em></em>, raw **).
- CASE3: a boundary inside an emphasis run (**bold** span covering **bo) rendered
the emphasis but MISNESTED span/element (<strong>bo</span>ld</strong>).
Token-aware fix (both, per the issue #33 comment):
- injectSentinels: clamp any sentinel offset that lands strictly inside a
delimiter run (* _ ~ `) to the run's start, so a sentinel never splits a run
(CASE1). Delimiters are invisible once rendered, so this only shifts the colored
boundary across markup. Drop spans that clamp to empty.
- sentinelsToSpans: replace the naive global split/join with a walker over the
rendered HTML that emits the cw-by-* span only around TEXT runs — closing it
before any <tag> and reopening after — so a span is always well-nested within
inline elements (one span segment per text run, CASE3). Tags are copied
verbatim with any stray sentinel stripped (no Private-Use-Area char leaks).
Pure, vscode-free, deterministic (INV-33). No regression: existing colorByAuthor /
renderReview cases stay green; the common no-emphasis case is byte-identical.
222 unit + 74/5 host E2E green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A pinned baseline with no changes since should read as a clean starting point,
but the F10 on-render still author-colored every block (colorByAuthor), painting
the whole document green/blue right after a pin. Now, when the baseline reason is
"pinned" and there are zero changes since (every diffBlocks op unchanged), the
on-render is fully clean — no change marks and no authorship coloring — while the
data-src block mapping (INV-36) and any pending proposals (review actions, not
annotations) are kept.
Scoped to the PIN specifically, not all zero-diff: a baseline advanced by a
machine-landing (accept) is also zero-diff but keeps its authorship coloring so
accepted Claude text stays blue (F10 INV-33). renderReview takes a `pinned`
option; the controller passes baseline.reason === "pinned" from both refresh and
the renderHtmlFor test seam.
- trackChangesModel.ts: renderReview gains the `pinned` RenderOption; when pinned
+ zero-diff, blocks render plain (no colorByAuthor).
- trackChangesPreview.ts: pass { pinned } through refresh + renderHtmlFor.
- unit: pinned+zero-diff → no cw-by-*; pinned+zero-diff still shows proposals;
zero-diff WITHOUT pin (machine-landing) keeps coloring (INV-33); real changes
after a pin re-color.
- s48PinClean host E2E: type → colored; pin → clean; edit → annotations return.
218 unit + 74/5 host E2E green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Document-edit flow SLICE-3 — completes reach→review→accept
(specs/coauthoring-document-edit-flow.md §7.2, INV-42). A single "Accept all"
gesture applies every pending proposal on the current document through the
existing F4 acceptById seam (block proposals take the INV-40 word-precise path
automatically), in descending anchor order so an earlier accept never invalidates
a later one, skipping (never force-applying) proposals that can't anchor and
reporting applied-vs-skipped. Batched application of the existing accept path — no
new mechanism; the webview posts intent only (INV-35). No confirmation dialog
(undo restores).
- proposalController.ts: acceptAllProposals(document) → {applied, skipped}
(descending order, orphan-skip); accept/acceptById gain a silent opt so the
batch suppresses N per-proposal orphan warnings in favour of one report.
- trackChangesPreview.ts: ToolbarMsg += {type:"acceptAll"}; handleWebviewMessage
routes it to a public acceptAll(document) that batches + reports.
- extension.ts + package.json: cowriting.acceptAllProposals command (active doc,
markdown-gated palette entry) for the non-webview path.
- media/preview.ts + shellHtml: "✓✓ Accept all" toolbar button, posting the
intent, shown only with ≥2 pending proposals (authorable, on-state).
- trackChangesModel.ts: diffToBlockHunks now emits one block-aligned hunk per
CHANGED block even when changed blocks are ADJACENT (treats changed blocks as
1:1 anchors alongside unchanged ones; gap-spans only cover add/remove runs
between anchors) — fixes adjacent changed blocks collapsing into one proposal.
- f12Accept host E2E (apply-all reconstructs; orphan skip + report; single
proposal; command registered/gated); MANUAL-SMOKE-F12 §3.
214 unit + 73/5 host E2E green. Completes the document-edit-flow cluster
(#42 reach + #47 review + #46 accept).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
BenStullsBets
benstull
Ben Stull