[Bug]: macOS desktop cannot read T3CODE_BITBUCKET_* from a shell profile, so Bitbucket auth cannot be configured

[LunarRed]

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Add the Bitbucket variables to a shell profile on macOS, either ~/.zprofile or ~/.zshrc:

   export T3CODE_BITBUCKET_EMAIL="you@example.com"
   export T3CODE_BITBUCKET_API_TOKEN="your-token"

2. Confirm the shell really has them: zsh -ilc env | grep T3CODE_BITBUCKET prints both.

3. Quit T3 Code with Cmd+Q, then reopen it from the Dock.

4. Open Settings, then Source Control.

5. Optional confirmation: take the server pid from ~/.t3/userdata/server-runtime.json and run ps eww <pid>. The variables are absent from the server environment.

Expected behavior

docs/user/source-control.md says to set T3CODE_BITBUCKET_EMAIL and T3CODE_BITBUCKET_API_TOKEN, or T3CODE_BITBUCKET_ACCESS_TOKEN, then restart T3 Code and verify in Source Control settings. Following that should authenticate Bitbucket.

Actual behavior

Bitbucket stays on "Not authenticated", showing "Set T3CODE_BITBUCKET_EMAIL and T3CODE_BITBUCKET_API_TOKEN on the server". No shell profile makes this work, and no number of restarts helps.

The cause is the launch context. When you open the desktop app from the Dock or Finder, launchd starts it, so the app's environment comes from launchd and your shell is never in the chain. The server is a child of the app and inherits the same environment, so a shell export cannot reach the config reader.

This is separate from the login shell env sync. That path carries PATH and tool discovery, not provider credentials.

Impact

Major degradation or frequent failure

Version or commit

0.0.32 (Alpha)

Environment

macOS 26.5.2, Apple Silicon, T3 Code (Alpha) desktop 0.0.32

Logs or stack traces

# variables are present in the login shell the app would read
$ zsh -ilc 'env' | grep -c T3CODE_BITBUCKET
2

# but absent from the running server process after a full restart
$ ps eww $(python3 -c "import json;print(json.load(open('$HOME/.t3/userdata/server-runtime.json'))['pid'])") \
    | tr ' ' '\n' | grep -c T3CODE_BITBUCKET
0

Workaround

Put the values into the launchd session, then quit T3 Code completely and open it again:

launchctl setenv T3CODE_BITBUCKET_EMAIL "you@example.com"
launchctl setenv T3CODE_BITBUCKET_API_TOKEN "your-token"

This is cleared on reboot, so it needs a LaunchAgent with RunAtLoad to set them again at login. open -a "T3 Code" --env NAME=VALUE also works, but only when launching from a terminal.

Suggested fix

Read the launchd session environment on macOS for T3CODE_* configuration, or support a config file the server reads for provider credentials.

At minimum the docs could cover it. Happy to send a docs-only PR adding something like this to docs/user/source-control.md if you want it:

macOS. If you open T3 Code from the Dock, it does not inherit variables that you export in a shell profile. Set them for your login session instead, then quit T3 Code completely and open it again.

launchctl setenv T3CODE_BITBUCKET_ACCESS_TOKEN "your-access-token"

Your Mac clears these values when it restarts. To keep them, add a LaunchAgent that sets them again at login.

Related, but not duplicates

• [Bug]: macOS login shell sync misses Homebrew and other env vars, causing terminal command errors #1465, macOS login shell sync misses Homebrew and other env vars. Closed as completed. That one is about the env sync feeding PATH and terminal behaviour. Provider credentials do not travel through that sync, so fixing it does not fix this.
• [Bug]: Provider paths not detected when launching from finder / dock (MacOS) #2329, provider paths not detected when launching from Finder or Dock. Same launch context, but about provider discovery rather than provider auth.

Investigated with Claude running in T3 Code.

[ashukumar2001]

I was facing the same issue, thanks for the workaround @LunarRed

[AbdelrahmanHafez]

Same issue with GitHub, so this is broader than the Bitbucket vars.

My gh is authenticated only through GH_TOKEN from a shell profile, with no ~/.config/gh/hosts.yml at all. Desktop 0.0.33 shows GitHub as "Not authenticated" and tells me to run gh auth login, which my shell considers already done. Same check as yours:

$ ps eww $(python3 -c "import json;print(json.load(open('$HOME/.t3/userdata/server-runtime.json'))['pid'])") \
    | tr ' ' '\n' | grep -c '^GH_TOKEN='
0

The login shell sync does run, and the variable is in scope for it. readLoginShellEnvironment spawns $SHELL -ilc in apps/desktop/src/shell/DesktopShellEnvironment.ts, but the command it runs is a printenv per name in LOGIN_SHELL_ENV_NAMES (PATH, locale, XDG, Homebrew, SSH_AUTH_SOCK). So the value is visible to the probe and never asked for. A server started from a terminal has no such problem, since VcsProcess passes no env override and gh inherits the server env.

#7620 handles the Windows side by adding the names to WSL_FORWARDED_ENV_NAMES, alongside OPENAI_API_KEY and ANTHROPIC_API_KEY. The macOS path differs in one way: LOGIN_SHELL_ENV_NAMES writes into the Electron process.env, so anything added there also reaches every provider subprocess. Provider API keys belong there. A GitHub PAT with admin:org and delete_repo does not, and VcsProcess already takes an env parameter, so credential vars can reach the source control adapters only.

Workaround, give gh an on-disk credential so it stops depending on the env:

env -u GH_TOKEN -u GITHUB_TOKEN gh auth login

[MichaelCharles]

Still present on 0.0.37 (macOS 26.6.2, Apple Silicon). Both vars in ~/.zshrc, present in zsh -ilc env, absent from the server process after a full restart.

The LaunchAgent workaround survives reboot: RunAtLoad running both launchctl setenv calls. Verified by launchctl unsetenv on both vars, re-bootstrapping the agent, and checking launchctl getenv returns them.

[MichaelCharles]

Opened #9022 for the macOS/Linux side of this.

The login-shell probe runs fine and the values are in scope, but readLoginShellEnvironment only requests names listed in LOGIN_SHELL_ENV_NAMES. It never asks for the Bitbucket variables, so they get dropped. The PR adds the three T3CODE_BITBUCKET_* names the server reads and hydrates them as one group (an access token outranks email + API token).

This doesn't cover GH_TOKEN (@AbdelrahmanHafez). Same root cause, but a PAT with admin:org reaching every agent subprocess is a different tradeoff. I think that one needs a maintainer decision rather than just adding it to the list.

[juliusmarminge]

Fixed by #14103 — Bitbucket credentials can now be saved from Settings → Source Control (no shell-profile env vars / restart required).