Choose the Claude Code / Codex account per project #8104

Activity

1. vicegold

   added

   enhancementNew feature or requestNew feature or request

   on Oct 3, 2026
2. github-actions commented on Oct 3, 2026

   

   github-actionsBot

   on Oct 3, 2026 – with GitHub Actions

   Contributor

   More actions

   Triage summary (feature request, not a bug)

   Right now Superset picks one Claude Code account and one Codex account for the whole machine, in Settings → Usage. Every agent launch reads that one choice, whatever project it belongs to. The request is a per-project override ("Agent accounts" in project settings, Default or any added account) that terminals, agent runs, and chat in that project's workspaces would use. Projects without an override keep the Usage default. The author links PR #8005 as an implementation. The code confirms the current behavior: account selection has no project input anywhere.

   Where the account is chosen today

   • Storage: packages/host-service/src/db/schema.ts:142-145. The selection lives on hostSettings (defaultClaudeConfigDir, defaultCodexHome). It is mirrored into machine-wide pointer files at $SUPERSET_HOME_DIR/state/default-claude-config-dir and default-codex-home by syncDefaultAccountPointer (packages/host-service/src/trpc/router/usage/default-account.ts:99).
   • Resolution: resolveDefaultAccountEnv(db, presetId) and resolveDefaultAccountTerminalEnv(db) (default-account.ts:251-301) take only db. No workspace or project goes in.
   • Every launch path goes through those two functions, with no project context:
     • Terminals: packages/host-service/src/terminal/terminal.ts:3105. workspaceId is already in scope here.
     • Chat: packages/host-service/src/chat-v3/agentEnv.ts:68. This file already looks up the workspace's project in workspacePaths().
     • Agent configs: agentLaunchEnv in packages/host-service/src/terminal-agents/agent-config.ts:105.
     • Session lookup: packages/host-service/src/terminal-agents/harness-session-ref.ts:48-50.
     • Trust seeding: packages/host-service/src/trpc/router/workspace-creation/shared/seed-agent-trust.ts:77.
     • Agent tooling: packages/host-service/src/trpc/router/agent-tooling/agent-tooling.ts:41.
   • Shell wrapper: buildDefaultAccountResolver (packages/agent-setup/src/agent-wrappers-common.ts:142-171) re-reads the machine-wide pointer file every time an agent starts. The wrappers for claude and codex use it (agent-wrappers-claude-codex-opencode.ts:298,317).

   Main design trap (for reviewing #8005)

   Setting a project's account in the PTY env at spawn is not enough on its own. The wrapper overrides CLAUDE_CONFIG_DIR / CODEX_HOME with the machine-wide pointer whenever the current value is empty or equals SUPERSET_DEFAULT_<VAR> (agent-wrappers-common.ts:158-167). resolveDefaultAccountEnv always sets both of those to the same value (default-account.ts:279-282, 294-297). So if a project pin is passed through the same SUPERSET_DEFAULT_* twin, the wrapper switches the agent back to the Usage default at launch. The bug would only show on the second and later agent starts in a terminal, or once the global default differs from the pin.

   The fix has to make the wrapper aware of the project. For example, the terminal env could carry a project pointer, or the project pin could be exported under a separate marker that the wrapper does not replace. SUPERSET_WORKSPACE_ID is already exported (packages/host-service/src/terminal/env.ts:301), but there is no project-ID env var today.

   Other things to check in a fix

   • Keep the existing order of precedence: an env var the user exported by hand wins, then a custom agent config's env, then the project pin, then the Usage default. Per-agent env wins today in agentLaunchEnv (agent-config.ts:101-106).
   • harness-session-ref.ts must resolve the same project-aware env. If it doesn't, transcript and session lookup will search the wrong account's store ("Anything that reads the agent's session store must look where this points", agent-config.ts:99).
   • If the pinned profile directory no longer exists, fall back to the Usage default, the same way resolveDefaultAccountEnv skips a missing profile today.
   • Schema precedent: projects.branchPrefixMode (schema.ts:97-100) already uses "null = follow the host-wide default". Two nullable columns on projects would follow the same pattern. Host DB migrations should go through .agents/skills/db-migrations/SKILL.md.
   • Any new project-settings procedure is called by released clients. See packages/trpc/AGENTS.md.
   • New UI strings need Lingui and translations (bun run check:i18n).

   How to check a fix

   1. Add two Claude accounts in Usage, A and B, and set the default to A.
   2. Pin project P to B.
   3. In a P workspace terminal, run claude and confirm it uses B (CLAUDE_CONFIG_DIR points at B's profile).
   4. Exit, run claude again in the same terminal, and confirm it still uses B. This is the wrapper re-resolve case above.
   5. Switch the Usage default to C and relaunch. P should stay on B, and an unpinned project should move to C.
   6. Repeat with chat (buildChatAgentEnv) and a preset agent run.

   A bun:test sketch: seed projects/workspaces, then assert that the project-aware resolver returns B's dir for P's workspace and the global pointer value for any other workspace. Add a node --test case next to default-account-resolver.test.ts that runs the generated wrapper block with the project env set and checks that the global pointer does not override the pin.

   Current workaround: a custom agent config can pin an account through its own env (e.g. CLAUDE_CONFIG_DIR), because per-agent env wins over the default (agent-config.ts:96-105). That works per agent, not per project.
3. lacherogwu commented on Nov 5, 2026

   

   lacherogwu

   on Nov 5, 2026

   More actions

   +1, same setup here: two Claude Max accounts (work + personal, the second via a CLAUDE_CONFIG_DIR home), with whole projects belonging to one or the other. Today I work around it with a custom agent that sets CLAUDE_CONFIG_DIR, but custom agents lose the native Claude model list and settings in the chat picker, so a per-project account pin with the native agent would be much better. Related request for a per-project default agent: #9393