Plugin requests macOS "control other applications" access it doesn't need #59

New Issue

2026-06-15T17:41:30Z

benstull commented

2026-06-15 17:41:30 +00:00

Plugin requests macOS "control other applications" access it doesn't need

Summary

Using the plugin triggers macOS's "wants access to control other
applications" (Automation / Apple Events) permission prompt — but the plugin
works fine when the user declines, so the access is unnecessary and the
prompt should never appear.

Problem / pain

A coauthoring tool that suddenly asks to control other applications reads as
alarming — it's the same prompt malware and automation tools trigger, and it
gives no reason tied to anything the user did. The user declines, and everything
keeps working normally, which proves the access isn't needed for the feature at
hand. The net effect is an unexplained, scary-looking system prompt that erodes
trust in the plugin and makes it feel less safe than it is, for zero functional
benefit.

Who feels it

Every macOS user of the plugin — the prompt fires on use, regardless of what
they're doing, the first time the triggering code path runs.

Steps to reproduce

On macOS, use the plugin (invoke the Claude edit / agent flow).
Observe macOS prompts: "⟨app⟩ wants access to control other applications."
Click Don't Allow.
Observe: the plugin continues to work normally — the declined access was not
needed.

Expected vs. actual

Expected: the plugin does not request Automation / "control other
applications" access; no such prompt appears during normal use.
Actual: the prompt appears on use; declining it has no functional impact.

Desired outcome / value

Normal use of the plugin never triggers a "control other applications" prompt.
The plugin only requests OS permissions it genuinely needs, so it reads as
trustworthy and behaves predictably on macOS.

Acceptance — "done right"

On a fresh macOS machine (or after resetting Automation TCC for the host app),
exercising the plugin's normal flows does not trigger the "control other
applications" / Apple Events prompt.
No regression in the feature that currently runs when the prompt is declined
(it already works declined — it must still work with the prompt gone).
The triggering code path is identified and the unnecessary
automation/Apple-Events call is removed or made not to fire (or, if it
originates upstream in @cline/sdk, the dependency is configured/updated to
not request it — see notes).

Scope / non-goals

In scope: stopping the plugin from requesting macOS Automation / "control
other applications" access during normal use.

Non-goals:

Permissions the plugin legitimately needs (if any) for an explicitly
user-invoked action.
Non-macOS platforms (this is a macOS TCC/Automation prompt specifically).
Broader sandboxing/entitlements review beyond this one spurious request.

Assumptions · constraints · dependencies

Lead, not a settled root cause: the extension's own source contains no
AppleScript / osascript / automation calls — the trigger appears to come from
@cline/sdk / @cline/core during agent activation (a likely suspect is
its local Claude Code hub-discovery), which falls back gracefully when the
permission is denied (explaining why declining works). Confirming the exact
trigger is the first task of the fix.
If the cause is upstream in @cline/sdk, the fix may be a config/flag to
disable the offending discovery, a dependency update, or an upstream issue —
rather than a change in this repo's own code.
macOS-specific (Automation/Apple Events TCC). Reproduction/verification needs a
macOS host and may require resetting the host app's Automation permission
(tccutil reset AppleEvents) between runs.

Source / signal

Self-originated — capture session vscode-cowriting-plugin-0053
(2026-06-15). Dev observation: "The plugin is asking for access to other
applications but works fine when I decline. It just shouldn't." Investigation
this session found no automation calls in the extension's own code; the probable
origin is @cline/sdk/@cline/core agent activation.

Priority (WSJF)

Provisional: Value 6 · Time-criticality 3 · Opportunity-enablement 2 ÷ Size 4 =
~2.75. priority/P1 (operator call) — functionally harmless (declining
works) but a serious trust / launch-optics problem: a "control other
applications" prompt from a writing tool is the kind of thing that makes users
distrust or uninstall, so it's treated as high priority despite the harmless
functional impact. Sizing is uncertain because the cause may be upstream in
@cline/sdk.

Decomposition

Single increment (Bug). Tasks:

Confirm the exact code path that triggers the Apple Events prompt
(instrument activation; bisect the @cline/sdk agent run / hub discovery).
Determine whether it's suppressible in this repo (config/flag) or requires
an upstream @cline/sdk change/update.
Remove / disable the unnecessary request; verify the prompt no longer fires
and the declined-path feature still works.
Verify on a clean macOS Automation-TCC state.

# Plugin requests macOS "control other applications" access it doesn't need ## Summary Using the plugin triggers macOS's **"wants access to control other applications"** (Automation / Apple Events) permission prompt — but the plugin works fine when the user **declines**, so the access is unnecessary and the prompt should never appear. ## Problem / pain A coauthoring tool that suddenly asks to **control other applications** reads as alarming — it's the same prompt malware and automation tools trigger, and it gives no reason tied to anything the user did. The user declines, and everything keeps working normally, which proves the access isn't needed for the feature at hand. The net effect is an unexplained, scary-looking system prompt that erodes trust in the plugin and makes it feel less safe than it is, for zero functional benefit. ## Who feels it Every **macOS user** of the plugin — the prompt fires on use, regardless of what they're doing, the first time the triggering code path runs. ## Steps to reproduce 1. On macOS, use the plugin (invoke the Claude edit / agent flow). 2. Observe macOS prompts: *"⟨app⟩ wants access to control other applications."* 3. Click **Don't Allow**. 4. Observe: the plugin continues to work normally — the declined access was not needed. ## Expected vs. actual - **Expected:** the plugin does not request Automation / "control other applications" access; no such prompt appears during normal use. - **Actual:** the prompt appears on use; declining it has no functional impact. ## Desired outcome / value Normal use of the plugin never triggers a "control other applications" prompt. The plugin only requests OS permissions it genuinely needs, so it reads as trustworthy and behaves predictably on macOS. ## Acceptance — "done right" - On a fresh macOS machine (or after resetting Automation TCC for the host app), exercising the plugin's normal flows does **not** trigger the "control other applications" / Apple Events prompt. - No regression in the feature that currently runs when the prompt is declined (it already works declined — it must still work with the prompt gone). - The triggering code path is identified and the unnecessary automation/Apple-Events call is removed or made not to fire (or, if it originates upstream in `@cline/sdk`, the dependency is configured/updated to not request it — see notes). ## Scope / non-goals **In scope:** stopping the plugin from requesting macOS Automation / "control other applications" access during normal use. **Non-goals:** - Permissions the plugin legitimately needs (if any) for an explicitly user-invoked action. - Non-macOS platforms (this is a macOS TCC/Automation prompt specifically). - Broader sandboxing/entitlements review beyond this one spurious request. ## Assumptions · constraints · dependencies - **Lead, not a settled root cause:** the extension's own source contains no AppleScript / `osascript` / automation calls — the trigger appears to come from **`@cline/sdk` / `@cline/core`** during agent activation (a likely suspect is its local Claude Code hub-discovery), which falls back gracefully when the permission is denied (explaining why declining works). Confirming the exact trigger is the first task of the fix. - If the cause is upstream in `@cline/sdk`, the fix may be a config/flag to disable the offending discovery, a dependency update, or an upstream issue — rather than a change in this repo's own code. - macOS-specific (Automation/Apple Events TCC). Reproduction/verification needs a macOS host and may require resetting the host app's Automation permission (`tccutil reset AppleEvents`) between runs. ## Source / signal Self-originated — capture session **vscode-cowriting-plugin-0053** (2026-06-15). Dev observation: "The plugin is asking for access to other applications but works fine when I decline. It just shouldn't." Investigation this session found no automation calls in the extension's own code; the probable origin is `@cline/sdk`/`@cline/core` agent activation. ## Priority (WSJF) Provisional: Value 6 · Time-criticality 3 · Opportunity-enablement 2 ÷ Size 4 = ~2.75. **`priority/P1`** (operator call) — functionally harmless (declining works) but a serious trust / launch-optics problem: a "control other applications" prompt from a writing tool is the kind of thing that makes users distrust or uninstall, so it's treated as high priority despite the harmless functional impact. Sizing is uncertain because the cause may be upstream in `@cline/sdk`. ## Decomposition Single increment (Bug). Tasks: - [ ] Confirm the exact code path that triggers the Apple Events prompt (instrument activation; bisect the `@cline/sdk` agent run / hub discovery). - [ ] Determine whether it's suppressible in this repo (config/flag) or requires an upstream `@cline/sdk` change/update. - [ ] Remove / disable the unnecessary request; verify the prompt no longer fires and the declined-path feature still works. - [ ] Verify on a clean macOS Automation-TCC state.

benstull added the priority/P1 type/bug labels 2026-06-15 17:41:37 +00:00

benstull referenced this issue from a commit

2026-06-26 20:11:24 +00:00

fix(#59): disable claude-code IDE auto-connect to stop spurious macOS Apple-Events prompt

benstull referenced a pull request that will close this issue

2026-06-26 20:12:11 +00:00

fix(#59): disable claude-code IDE auto-connect to stop spurious macOS Apple-Events prompt #68

benstull closed this issue

2026-06-26 20:12:24 +00:00

benstull referenced this issue from a commit

2026-06-26 20:12:25 +00:00

fix(#59): disable claude-code IDE auto-connect to stop spurious macOS Apple-Events prompt (#68)