[Bug]: macOS TCC permission prompts attributed to T3 Code are raised by agent CLI probes at startup #5285

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

On macOS, T3 Code spawns the configured agent CLIs at startup to probe them. Because those spawns are children of the Electron app, macOS TCC attributes their privacy requests to T3 Code, so permission dialogs appear under the name "T3 Code (Alpha)" seconds after launch, before the user has opened a project, started a session, or taken any action.

The app itself is not requesting these resources. I grepped the shipped 184MB app.asar for path construction into Documents/Desktop/Downloads/iCloud and found no genuine hits. The requests originate entirely from the probed agent binary.

Steps to reproduce

1. On macOS, have Claude Code installed and authenticated.
2. Reset T3 Code's TCC state so grants are not already cached:

   tccutil reset SystemPolicyAllFiles com.t3tools.t3code
   

3. Start a TCC log capture:

   log stream --predicate 'subsystem == "com.apple.TCC"' --style compact
   

4. Launch T3 Code. Do not click anything, do not open a project, do not start a session.
5. Watch the capture for roughly 5 seconds.

Expected behavior

Launching the app without opening a project or starting a session should not cause macOS privacy requests attributed to T3 Code. Agent CLI probing should either be deferred until the user actually opens a project or starts a session, or be done in a way that does not surface OS-level permission dialogs under the app's name.

Actual behavior

About 3.5 seconds after launch, with no user interaction, tccd records a kTCCServiceSystemPolicyAllFiles request in which the accessing process is the Claude Code binary, the responsible process is T3 Code, and AUTHREQ_SUBJECT resolves to com.t3tools.t3code. Full log excerpt below.

The AUTHREQ_SUBJECT field is what determines the wording of the dialog, so any prompt raised by a probed agent reads as though T3 Code is asking for the user's files.

The spawn is observed empirically (a claude-code process appears as a descendant of the app within ~3.5s of launch). The candidate origins in main are:

• apps/server/src/provider/Layers/ClaudeProvider.ts:827 runs runClaudeCommand(claudeSettings, ["--version"], ...) as a health check inside checkClaudeProviderStatus.
• apps/server/src/provider/Drivers/ClaudeDriver.ts:160 calls probeClaudeCapabilities to read account and slash-command metadata.

I did not instrument which of the two fired on this particular launch, only that a probe of the agent binary happens without user interaction and that its TCC requests are attributed to the app.

Worth noting: on the launch I captured, the Full Disk Access request was a preflight query (preflight=yes, query=1), which does not by itself draw a dialog. A visible dialog additionally requires the probed agent to touch a protected location. But the attribution is established at probe time regardless, which is the part that seems wrong: the user is asked to grant filesystem access to T3 Code for work that a separate, independently installed tool is doing.

Impact

Minor bug or occasional failure

Version or commit

0.0.31 (desktop, Alpha channel)

Environment

macOS 26.6 (build 25G72), Apple Silicon, T3 Code (Alpha) 0.0.31 from /Applications, Node 26.0.0, provider: Claude Code 2.1.220

Logs or stack traces

# log stream --predicate 'subsystem == "com.apple.TCC"' --style compact
# username redacted, app launched at 08:10:16, no user interaction

08:10:19.774 tccd REQUEST: function=TCCAccessRequest, msgID=46152.1074
08:10:19.778 tccd AUTHREQ_CTX: msgID=46152.1074, function=TCCAccessRequest,
             service=kTCCServiceSystemPolicyAllFiles, preflight=yes, query=1
08:10:19.778 tccd AUTHREQ_ATTRIBUTION: msgID=46152.1074, attribution={
               responsible={identifier=com.t3tools.t3code, pid=6978,
                 responsible_path=/Applications/T3 Code (Alpha).app/Contents/MacOS/T3 Code (Alpha),
                 binary_path=/Applications/T3 Code (Alpha).app/Contents/MacOS/T3 Code (Alpha)},
               accessing={identifier=com.anthropic.claude-code, pid=7160,
                 binary_path=/Users/<user>/.local/share/claude/versions/2.1.220},
               requesting={identifier=com.apple.sandboxd, pid=46152,
                 binary_path=/usr/libexec/sandboxd}}
08:10:19.793 tccd AUTHREQ_SUBJECT: msgID=46152.1074, subject=com.t3tools.t3code
08:10:19.795 tccd -[TCCDAccessIdentity staticCode]: static code for:
             identifier com.t3tools.t3code, type: 0 at /Applications/T3 Code (Alpha).app
08:10:19.811 tccd AUTHREQ_RESULT: msgID=46152.1074, authValue=0, authReason=5

Process tree at the time, showing the spawn chain that produces the attribution:

  PID  PPID COMM
 6978     1 /Applications/T3 Code (Alpha).app/Contents/MacOS/T3 Code (Alpha)
    └ server  /Applications/T3 Code (Alpha).app/Contents/MacOS/T3 Code (Alpha)
                app.asar/apps/server/dist/bin.mjs --bootstrap-fd 3
       └ 7160  claude-code (probe)

Workaround

None that preserves the feature. Granting T3 Code Full Disk Access silences the dialogs but extends that reach to every agent process the app subsequently spawns, which is a strictly worse security posture than leaving it denied.