Sign up
View stargazersSign up

macOS service updates require new privacy approvals for each versioned t3 executable#17225

opened26d agobyRrashidgg

What happened

I run T3 Code as a background service on my Mac so I can access my threads from other computers and mobile devices.

After server updates, macOS asks me to approve folder access again. I also get notifications saying t3 was blocked from App Management.

System Settings now contains multiple entries named t3 under both App Management and Full Disk Access. Approving one version does not cover subsequent versions.

Expected behavior: permissions granted to the service should persist across updates without requiring another local approval for every new executable path. Repeated prompts are particularly disruptive when updating an unattended remote host.

Diagnosis

The service runs executables from version-specific directories:

text
1<T3_HOME>/runtime/versions/<version>/t3

Read-only inspection of macOS’s system TCC database confirmed that the service’s Full Disk Access entries are keyed to these executable paths (client_type = 1). Multiple releases have separate permission records.

The compared binaries are already Developer ID signed and have identical designated requirements:

text
1Identifier: t3
2TeamIdentifier: ARK85ZXQ4Z

The changing executable path is therefore the confirmed identity difference associated with the separate Full Disk Access records.

The source matches the observed installation:

  • bootService.ts configures the service to run the pinned runtime executable with __service-launcher.
  • serviceLauncher.ts constructs the version-specific executable path and launches it with serve.

A stable command symlink alone would not change the version-specific server executable selected by this launcher.

The App Management notifications were reported by the user, and duplicate entries are visible in the supplied screenshot. The specific operation triggering that notification was not captured during triage.

Steps to reproduce

Reported reproduction; no additional update or permission reset was performed during triage:

  1. Install and run T3 Code as a macOS background service.
  2. Approve folder access and grant the current t3 executable Full Disk Access.
  3. Update the server to another nightly release and allow the service to switch to the new runtime.
  4. Perform agent work that accesses protected folders.
  5. Observe renewed permission prompts and another t3 entry in System Settings.
  6. Repeat server updates; separate permission entries accumulate.

Version

Active server: 0.0.46-nightly.20261008.2819
Source commit: 5e2225671f705fcd33f1ea5591b79ba612fb6974

The npx t3 triage CLI reported version 0.0.45; the running service version was verified separately.

Environment

macOS 27.0.1, build 26A434; Apple Silicon arm64; launchd user service. Remote access from other computers and mobile devices. Node v26.8.2 reported by triage.

Evidence

<T3_HOME> replaces the user’s installation root.

text
1launchd ProgramArguments:
2<T3_HOME>/runtime/versions/0.0.46-nightly.20261007.2787/t3
3__service-launcher
4
5Service state activeVersion:
60.0.46-nightly.20261008.2819
7
8Selected system TCC records:
9service: kTCCServiceSystemPolicyAllFiles
10client_type: 1
11
12Version auth_value
130.0.43-nightly.20260928.2375 2
140.0.44-nightly.20260929.2456 2
150.0.46-nightly.20261003.2632 0
160.0.46-nightly.20261007.2787 0
17
18Each client path:
19<T3_HOME>/runtime/versions/<version>/t3

Screenshots show multiple t3 entries under App Management and Full Disk Access:

Image Image

#5285 concerns permissions attributed to the desktop app during agent CLI probes at startup. This report concerns previously granted permissions failing to carry across CLI service updates that change the executable path. No exact duplicate was found.

Fix applied or workaround

No service configuration, binaries, or permission databases were modified. Reapproving individual executable versions provides temporary access but does not address subsequent updates.

Please provide a supported service installation/update mechanism that preserves macOS permission identity across releases.

Filed by

Codex, GPT-6 family, via t3 triage.

Zziyadakl26d ago
Synced from GitHub

Confirmed the cause on macOS 27. TCC stores the grant for the launch agent's program by path: TCC.db shows client=~/.t3/runtime/versions/<version>/t3, client_type=1. Every update changes that path.

Only the launch agent's path matters. I ran a test launch agent at a fixed path and granted Full Disk Access to that path only. Children started from two other paths could both read ~/Library/Safari. Before the grant, both got errno=1.

Proposed fix: on macOS, t3 service install copies versions/<v>/ to runtime/launcher/, and the plist runs runtime/launcher/t3 __service-launcher. serve still runs from versions/<v>. Running in my fork since today: https://github.com/ziyadakl/t3code/pull/13. The grant on runtime/launcher/t3 covers serve from a fresh version folder.

Happy to open a PR against main if this direction works for you.

Jjssblck25d ago
Synced from GitHub

Same root cause on two Macs here, and it reaches past Full Disk Access. Processes an agent starts are checked against the service's versioned t3 as their responsible process, so Screen Recording and Accessibility grants go there too, and an update drops them.

System TCC.db rows with client = ~/.t3/runtime/versions/<version>/t3, client_type = 1:

MacServiceVersionauth_value
1kTCCServiceAccessibility0.0.43-nightly.20260923.21502
1kTCCServiceScreenCapture0.0.43-nightly.20260923.21502
1kTCCServiceSystemPolicyAllFiles0.0.46-nightly.20261003.26100
1kTCCServiceSystemPolicyAllFiles0.0.46-nightly.20261008.28330
2kTCCServiceAccessibility0.0.43-nightly.20260922.21102
2kTCCServiceScreenCapture0.0.46-nightly.20261003.26100

Mac 1 runs 0.0.46-nightly.20261009.2861 (launchd) and 20261009.2886 (its child) and has no row for either. It took three nightlies in about a day, so a grant lasts hours.

The Screen Recording row on Mac 1 was written at 2026-09-29 20:42:37 UTC, the minute a coding agent's screencapture failed in a T3 thread and the user granted access to "the app that runs my shell". The grant landed on that version's t3, not on T3 Code.app. Agents in other T3 threads on both Macs have hit screencapture ("could not create image from display") and System Events through osascript ("osascript is not allowed assistive access").

+1 to the fixed launcher path proposed above. It would keep these grants as well as Full Disk Access.