Repository navigation
[Bug]: docs/providers/claude.md still documents HOME-based Claude homes, but the app now uses CLAUDE_CONFIG_DIR — breaks logins for existing multi-account setups #4696
Description
Activity
Same happening with 0.0.30. It is not worth the hassle, so pinned my version to 0.0.28.
Also failing on previous version, workaround on windows for me was to set
set CLAUDE_CONFIG_DIR=C:\Users\username\claude-second\.claude-second, set same env var in T3-Code, and disconnect/reconnect second claude provider.But the bug now seems to be fixed in 0.0.32 nightly, at least for new profiles we can have both sitting at
C:\Users\username\.claude and C:\Users\username\.claude-secondPartial status update, in case it helps triage: the doc file named in this issue no longer exists.
docs/providers/claude.mdnow 404s — the guide lives at
docs/user/providers-claude.md,
and it already teaches the correct flow:CLAUDE_CONFIG_DIR=~/.claude_personal_home claude auth login,
a "work and personal accounts" section, and an explicit "UseCLAUDE_CONFIG_DIR, notHOME" note.
So the primary ask of this issue (stop documenting HOME-based homes) appears already done.What still looks unaddressed:
- No migration note for HOME-era setups. Someone who configured a home before the change has their
config root at<path>/.claude/, and nothing tells them to movesettings.json,skills/,plugins/,
projects/up into<path>/and re-login throughCLAUDE_CONFIG_DIR. - No warning about the destructive old command.
HOME=... claude auth loginwrites credentials to the
default home, so following the old instructions to "fix" a broken instance silently overwrites the other
account's login while leaving the broken one broken. That's the part that actually costs people an account,
and it's worth one bold line in the guide.
For whoever picks this up, the current behavior in the 0.0.32 bundle is unambiguous — no HOME fallback remains
anywhere in the Claude driver:ClaudeSettings.homePath(UI: "CLAUDE_CONFIG_DIR path") is exported asCLAUDE_CONFIG_DIRby
makeClaudeEnvironment;HOMEis untouched.- thread continuation key is
claude:home:<resolved path>, and the capabilities cache key is
binaryPath \0 resolvedHome \0 cwd.
And the resulting on-disk layout, confirmed with Claude Code 2.1.226 (
CLAUDE_CONFIG_DIR=/tmp/probe claude -p ...):
.claude.json,projects/,sessions/,backups/are created directly in the config dir, with no nested
.claude/— which is exactly why HOME-era directories stop resolving.- No migration note for HOME-era setups. Someone who configured a home before the change has their
Note
🤖 GPT-5.6 Sol in Codex responding on behalf of Theo
Closing as resolved. The replacement Claude guide documents CLAUDE_CONFIG_DIR and separate accounts.
Before submitting
Area
Docs
Steps to reproduce
docs/providers/claude.md, set up a second Claude provider instance with aClaude HOME path(e.g.~/.claude_work_home) and log it in as the docs describe:HOME=~/.claude_work_home claude auth loginExpected behavior
The provider keeps working after the update, or the docs describe how to migrate / re-login.
Actual behavior
Every turn fails with
Not logged in · Please run /login(authentication_failedin the provider logs), while the Providers panel still shows the instance as "Authenticated".Cause: the app now launches Claude with
CLAUDE_CONFIG_DIR=<home path>instead ofHOME=<home path>. That changes two things for pre-existing setups:<path>/.claude/to<path>/directly, so existing settings, skills, plugins, and session history are no longer found;Claude Code-credentials-<first 8 hex of sha256(path)>instead of the entry the old HOME-based launch used), so existing credentials are not found either.The docs still describe the old behavior. Worse, the documented login command (
HOME=... claude auth login) writes credentials to the default home — so a user trying to fix the broken provider can silently overwrite their other account's credentials while never fixing the broken one (this happened to me).Impact
Major degradation or frequent failure — multi-account users cannot send messages on the affected provider after updating, and following the documented login flow makes things worse.
Version or commit
T3 Code (Alpha) 0.0.29, Claude CLI 2.1.220
Environment
macOS 15 (Darwin 24.5.0), desktop app
Logs or stack traces
Workaround
plus manually copying
settings.json,skills/,plugins/, andprojects/from<home>/.claude/to<home>/.Suggested doc fix: update the login commands in
docs/providers/claude.mdto useCLAUDE_CONFIG_DIR=...instead ofHOME=..., and add a short migration note for setups created before the change.