[Bug]: T3 Code repeatedly asks for data access on macOS

What happened

On macOS, both stable and Nightly T3 Code builds repeatedly say that T3 Code needs access to data from other apps. Selecting Allow does not stop later prompts. A prompt can also appear after T3 Code is fully quit with Cmd+Q, which interrupts other work.

Before submitting

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

Area

apps/desktop

Steps to reproduce

Install and start a stable or Nightly T3 Code build on macOS with the macOS Tailscale app installed.
Let T3 Code read its connection and server configuration.
Select Allow when macOS says that T3 Code needs access to data from other apps.
Continue to use T3 Code, or quit T3 Code with Cmd+Q.
Observe that the prompt appears again.

Expected behavior

Passive connection discovery must not cause repeated macOS data-access prompts. After T3 Code quits, it must not cause another prompt.

Actual behavior

The data-access prompt appears more than once, even after the user selects Allow. It can appear again after T3 Code is fully quit with Cmd+Q.

Impact

Major degradation or frequent failure

Version or commit

Stable and Nightly T3 Code builds

Environment

macOS with the macOS Tailscale app installed

Cause

Passive configuration and endpoint reads run tailscale status --json. On macOS, this starts a binary inside the Tailscale application bundle. macOS attributes that data access to T3 Code, so each later read can cause another prompt. A newer remote-open target path does not use the earlier desktop cache.

This is related to #2737, where users reported the problem in both stable and Nightly builds. This report covers the current regression and its newer passive discovery path.

Proposed fix

PR #11920 replaces passive Tailscale command calls with operating-system network interface and resolver discovery. Explicit pairing and dev-share operations continue to use Tailscale commands.

Logs or stack traces

None available.

Workaround

These actions can reduce or stop the prompts until the fix is available:

Use the repository directory as the project root. Do not create a project rooted at ~, ~/Documents, or another broad parent directory.
If remote access is not required, open Settings → Connections and disable Network access. T3 Code restarts in local-only mode.

Still happening for me on stable T3 Code (Beta) 0.1.8, and still present on 0.1.9 (latest stable): it ran tailscale.readTailscaleOutput <- RemoteOpenTargets.resolveTargets at launch (15:03:58), nothing while idle for 20 min, then again immediately after a View → Reload at 15:24 (well past the 60 s cache). macOS 27.2.1, Tailscale.app 1.104.7 (System Extension variant, /usr/local/bin/tailscale is the shell wrapper that execs /Applications/Tailscale.app/Contents/MacOS/tailscale).

From my ~/.t3/userdata/logs/server.trace.ndjson*, every Tailscale CLI spawn comes from the same chain, triggered by a client (re)connect:

tailscale.readTailscaleOutput <- RemoteOpenTargets.resolveTargets <- ws.rpc.subscribeServerConfig <- GET

8 spawns in ~24h, spaced 3 min to several hours apart (e.g. 09:39, 09:52, 12:00, 12:44, 12:54, 13:01, 13:05). While the app sat idle for 90 s with no reconnect, no tailscale process was spawned, so it is connect-driven, not a timer.

On current main (c7a3f02), RemoteOpenTargets wraps discovery in makeStaleWhileRevalidate(..., "60 seconds"), but since reconnects are minutes apart, that TTL doesn't stop the spawns: each reconnect after 60 s still runs readTailscaleStatus via the app-bundle binary. So the passive RemoteOpenTargets path is what triggers it in practice here (I don't have Tailscale Serve enabled, so DirectEndpoints never showed up in my traces). A short TTL alone won't fix it; it needs either a cache keyed on the tailnet interface addresses (as #26103 does) or a process-free lookup.

Happy to test a build of #26103 (or a follow-up) on this setup.

Note on the workaround in the issue body: on 0.1.9, turning off Settings → Connections → Network access does not stop this. subscribeServerConfig calls RemoteOpenTargets.resolveTargets() unconditionally, and discoverTargets runs readTailscaleStatus regardless of network exposure.

A workaround that does work (until a fix lands): T3 resolves tailscale from PATH, and on macOS the only copy there is the /usr/local/bin/tailscale wrapper that the Tailscale app's "Install CLI" option adds. Removing it stops the spawns:

sudo rm /usr/local/bin/tailscale
# optional: keep the CLI in your own shell without exposing it to T3
echo "alias tailscale=/Applications/Tailscale.app/Contents/MacOS/tailscale" >> ~/.zshrc

Checked on 0.1.9: after removing it, a View → Reload logs RemoteOpenTargets.resolveTargets → tailscale.readTailscaleOutput as Failure and no tailscale process starts. Tailscale itself keeps working. The trade-off is that T3's Tailscale-based features (Tailscale HTTPS / MagicDNS remote-open targets) are unavailable. "Install CLI" in the Tailscale app restores the old behavior.

Navigation Menu

Repository navigation

[Bug]: T3 Code repeatedly asks for data access on macOS #11929

What happened

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Cause

Proposed fix

Logs or stack traces

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: T3 Code repeatedly asks for data access on macOS #11929

Description

What happened

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Cause

Proposed fix

Logs or stack traces

Workaround

Activity

HlisTilen commented on Nov 13, 2026

HlisTilen commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions