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

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

• #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.
• #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.

Start with the macOS desktop launch path under apps/desktop and compare it with the credential instructions in docs/user/source-control.md. Reproduce the Dock or Finder launch and inspect the server environment described by ~/.t3/userdata/server-runtime.json. Done means Bitbucket credentials work when T3 Code is launched normally, or the documented launchd workaround is accurate and tested.