“Visual Studio Code.app” would like to access data from other apps.

[pelicanmedia]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: Version: 1.124.0 (Universal) Commit: 1b50d58
• OS Version: macOS 26.5.1 (25F80)

Steps to Reproduce:

1. Open VSCode on Mac
2. Get a warning every time

[potter0815]

This dialog is useless from a security perspective because it says "would like to access data from other apps" without specifying which apps. Users can't make an informed consent decision when the system provides zero detail about what's actually being accessed.

This is a failure on two fronts:

1. VS Code shouldn't be triggering cross-app data access requests this aggressively (the file watcher was supposedly fixed in “Visual Studio Code” would like to access data from other apps. #208105, yet here we are again)
2. macOS TCC provides no useful information — "other apps" is meaningless without specifics

At minimum, VS Code should document exactly what triggers this and provide a way to suppress it. Ideally, whatever component is requesting cross-app access should be scoped more narrowly so the dialog isn't triggered in the first place.

[vlsd]

This looks like the "responsible process" attribution from #307364. The prompt loop happens because the stored grant can never re-validate.

Repro: run any binary with its own signing identity from the integrated terminal — I used op (1Password CLI, signed com.1password.op, Team 2BUA8C4S2C). Click Allow, run it again 30s later, prompt returns. Same binary from iTerm2 never prompts.

log show --predicate 'process == "tccd"' shows why:

# VS Code
AUTHREQ_PROMPTING: Resp:{identifier=com.microsoft.VSCode, binary_path=/opt/homebrew/.../op}

# iTerm2 (no prompt)
AUTHREQ_ATTRIBUTION: accessing={identifier=com.1password.op, binary_path=/opt/homebrew/.../op}

VS Code doesn't disclaim responsibility, so the child inherits VS Code's identity. TCC stores a grant labeled com.microsoft.VSCode but validates it against the running code, which is signed by AgileBits (2BUA8C4S2C), not Microsoft (UBF8T346G9). Never matches. Over one day I logged 17 TCCDEvent: type=Create for this service/client and 1 type=Delete — every Allow writes a row that's never used again.

iTerm2 disclaims, so the child gets its own identity and the grant sticks after one Allow.

Note this is the inverse symptom of #307364, which describes requests being silently denied for want of NS*UsageDescription keys. SystemPolicyAppData prompts instead, so same cause, opposite behavior. PR #321762 should fix both.

macOS 26.5.2, VS Code 1.129.1. Both apps pass codesign --verify; neither has FDA.

[fulldecent]

I am noticing this in tandem with VS Code asking to login to GitHub Code Pilot every time I open the app.

I choose "Don't allow" on this popup every time. And Copilot works fine after I sign in each time.

System: macOS 26.5.2 (25F84) / lockdown mode enabled

[Kentzo]

log show --predicate 'process == "tccd"' shows why:

This is a better filter:

log show --predicate '(subsystem == "com.apple.TCC" && category == "access" && eventMessage CONTAINS[c] "identifier=com.microsoft.VSCode")' --style compact

In my case VSCode tried to access /Applications/Docker.app/Contents/Resources/bin/docker-credential-desktop.

[michaelgfeldman]

For anyone with Pylance installed, see microsoft/pylance-release#8197 — Pylance watches . recursively with no workspace open.