Per-project GitHub account, for T3 Code and the agents it starts #15383

Problem

I'm logged into two GitHub accounts in gh, a personal one and a work one. Most of my GitHub work is personal, but some open source repos we use at work need the work account.

More than once, an agent running in T3 Code opened a pull request or an issue under the wrong account. Agents call gh themselves, and gh uses whichever account is active. T3 Code starts every agent with the same environment, so nothing ties a project to an account. Some agents also run gh auth switch when a call fails, which changes the account for every session after it.

Wrong-account posts are public and hard to undo. Pull requests can't be deleted at all, and issues only by a repo admin, so the post usually stays up while I repost from the right account.

What exists

• Provider instances already have environment variables (Settings > Providers). A "Claude (work)" instance with GH_TOKEN set, used as the work projects' default model, works today. But it's chosen per thread, not enforced per project: picking the other instance in the model picker brings the wrong account back. It also means pasting a copy of the token into settings, once per provider.
• Per-project GitHub CLI account selection #13103 and Per-project GitHub account for the PR section #7472 ask for a per-project account for T3 Code's own GitHub calls, like the PR list and creating a PR. Per-project GitHub CLI account selection #13103 explicitly leaves agents and terminals out, but agents are where my wrong-account posts came from.
• [Feature]: Per-project environment variables #6715 asks for general per-project environment variables. It would work, but every user would need to know that GH_TOKEN is the right variable, and it would still mean storing a token.
• fix(pull-requests): scope GitHub reads and viewers to each workspace #14218 groups GitHub reads by credential and tracks the viewer per project. A per-project account would plug into that.

Proposal

A GitHub account setting in project settings. It lists the accounts gh auth status reports for the project's host, plus "Default (active gh account)", which keeps today's behavior.

When a project has an account selected:

1. T3 Code's own GitHub calls for that project use that account's token, from gh auth token --hostname <host> --user <login>. This is the Per-project GitHub CLI account selection #13103 part, built on fix(pull-requests): scope GitHub reads and viewers to each workspace #14218's per-credential reads.
2. When T3 Code starts an agent session in that project, it sets GH_TOKEN (GH_ENTERPRISE_TOKEN on Enterprise hosts) in the provider process's environment, from the same lookup. Every command the agent runs inherits it. GH_TOKEN takes priority over the active account, so gh acts as the chosen account even after a gh auth switch. MCP servers that read a token from their environment can reference the same variable. The agent isn't told anything and can't skip a step.

This needs no new plumbing in the adapters. Every adapter already adds per-session variables to the provider process at spawn, for the agent device tools (withAgentDeviceEnvironment in apps/server/src/mcp/McpProviderSession.ts). The token would go in the same place.

T3 Code doesn't store the token. It's read from gh when a session starts, so the keyring stays the source of truth and token rotation needs no settings change.

Changing the account

The account is looked up when a session starts, so existing threads pick up the setting the next time their agent starts. After an update, that's the first message in each thread, since the server restart stops every agent process.

Changing the setting while sessions are running must not leave any turn on the old account, except the one already in progress. T3 Code already restarts a thread's session at the start of a turn when its runtime mode, working directory, or provider instance changed, and resumes the conversation (ProviderCommandReactor). The session would also record the account it started with, and a mismatch would trigger the same restart:

• An idle session restarts when its next turn starts. An idle agent can't act before then, so restarting it right when the setting changes would add nothing.
• A running turn finishes with the account it started with. The next turn, including a queued follow-up, restarts the session with the new account.

Moving a thread to another project works the same way: its next turn uses the new project's account.

If the selected account is no longer logged in, settings and the PR view say so, and new turns in that project fail with that message. T3 Code doesn't fall back to the active account, because that fallback is the exact failure this setting is meant to prevent.

Out of scope

• MCP servers that sign in with OAuth, like GitHub's remote MCP, keep their own login in the provider's config directory. T3 Code can't switch it per project.
• Git commit authorship and SSH push identity. Git already has per-folder config for those (includeIf).
• Hosts other than GitHub. GitLab's glab reads GITLAB_TOKEN, so the same shape could work later.

Questions for maintainers

• Is passing a token into agent environments acceptable? Agents can already run gh auth token and get the active account's token, so this narrows access more than it widens it.
• Should the setting live in project settings (stored per environment, never in t3.json), or as a per-project override in Source Control settings, as Per-project GitHub CLI account selection #13103 suggests?
• Should a missing account block new turns, as proposed, or only show a warning?

I'm happy to implement this, with focused tests, once #14218 lands. I can also test #14218 with two real accounts in the meantime, since its PR notes that hasn't been done.