Problem
MonoCode's Claude harness resolves and drives exactly one claude binary — the one it finds at a fixed set of paths / via a login-shell PATH lookup (src-tauri/src/harness.rs::resolve_claude). There's no way to point MonoCode at a different Claude Code account/profile than whatever is currently the default at ~/.claude.
This matters for anyone juggling multiple Claude Code logins today (e.g. a work account and a personal account), which people commonly do via shell aliases like:
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'
alias claude-personal='CLAUDE_CONFIG_DIR=~/.claude-personal claude'
None of this reaches MonoCode:
- Aliases only exist inside an interactive shell session — they're invisible to
resolve_claude's file-based lookup.
- MonoCode does shell out to a login+interactive shell (
zsh -lic printenv) to read a few env vars, but that's a hardcoded 6-key allowlist (PATH, AI_GATEWAY_API_KEY, FX_AI_GATEWAY_API_KEY, VERCEL_OIDC_TOKEN, XAI_API_KEY, GROK_CODE_XAI_API_KEY) unrelated to Claude — so even setting CLAUDE_CONFIG_DIR in .zshrc never reaches the spawned claude process.
- The harness registry (
registerBuiltinHarnesses) only has one slot per provider id — there's no concept of multiple named instances of the same provider.
Net effect: whichever account is the unaliased default at ~/.claude is the only one usable from inside MonoCode. The other accounts are only reachable from a regular terminal, outside the app.
Suggested direction
Some form of a per-provider account/profile picker for Claude (and potentially other providers with the same multi-login pattern), e.g.:
- Let a project (or a session) pin a specific
CLAUDE_CONFIG_DIR (or equivalent) to use when spawning claude for it, instead of always relying on the environment default.
- Surface configured profiles in the same place model/provider selection already lives, rather than requiring the user to change global default credentials and restart the app to switch.
I don't have a concrete design opinion yet — flagging this as a real gap I hit, per CONTRIBUTING.md's guidance to open an issue before attempting anything that changes product shape. Happy to discuss the approach or pick it up if it's welcome.
Problem
MonoCode's Claude harness resolves and drives exactly one
claudebinary — the one it finds at a fixed set of paths / via a login-shell PATH lookup (src-tauri/src/harness.rs::resolve_claude). There's no way to point MonoCode at a different Claude Code account/profile than whatever is currently the default at~/.claude.This matters for anyone juggling multiple Claude Code logins today (e.g. a work account and a personal account), which people commonly do via shell aliases like:
None of this reaches MonoCode:
resolve_claude's file-based lookup.zsh -lic printenv) to read a few env vars, but that's a hardcoded 6-key allowlist (PATH,AI_GATEWAY_API_KEY,FX_AI_GATEWAY_API_KEY,VERCEL_OIDC_TOKEN,XAI_API_KEY,GROK_CODE_XAI_API_KEY) unrelated to Claude — so even settingCLAUDE_CONFIG_DIRin.zshrcnever reaches the spawnedclaudeprocess.registerBuiltinHarnesses) only has one slot per provider id — there's no concept of multiple named instances of the same provider.Net effect: whichever account is the unaliased default at
~/.claudeis the only one usable from inside MonoCode. The other accounts are only reachable from a regular terminal, outside the app.Suggested direction
Some form of a per-provider account/profile picker for Claude (and potentially other providers with the same multi-login pattern), e.g.:
CLAUDE_CONFIG_DIR(or equivalent) to use when spawningclaudefor it, instead of always relying on the environment default.I don't have a concrete design opinion yet — flagging this as a real gap I hit, per CONTRIBUTING.md's guidance to open an issue before attempting anything that changes product shape. Happy to discuss the approach or pick it up if it's welcome.