[BUG] Interactive session with custom CLAUDE_CONFIG_DIR writes no transcript JSONL anywhere (headless -p works) — 2.1.207+
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet (closest are #75424/#55456, which are about MCPs/settings bleed — not transcript loss)
- [x] This is a single bug report
Environment
- Claude Code: 2.1.208 (first observed on 2.1.207)
- OS: Linux ARM64 (Kali rolling, ClockworkPi uConsole CM4)
- Terminal: VTE and plain PTY (reproduces in both; no sandbox involved)
What's Wrong?
When running an interactive session with a custom CLAUDE_CONFIG_DIR (isolated profile, logged in via /login inside that profile), the conversation works normally on screen, but no session transcript is ever written — projects/<cwd-slug>/<session-id>.jsonl is not created under the custom dir, and nothing is written under the default ~/.claude either. The session is unrecoverable (--resume has nothing to resume) and any tooling that reads transcripts (usage/cost meters) sees nothing.
Other files ARE written to the custom dir during the same session: shell-snapshots/, session-env/<session-uuid>, .claude.json (project entry + history), and an empty sessions/ directory appears.
What works, same binary, same day:
- Headless
claude -p "..."with the same customCLAUDE_CONFIG_DIR→ transcript written correctly to$CLAUDE_CONFIG_DIR/projects/<slug>/<id>.jsonl. - Interactive with the default config (no
CLAUDE_CONFIG_DIR) → transcript written correctly.
Steps to Reproduce
export CLAUDE_CONFIG_DIR=~/claude-profile-test
claude # complete /login inside this profile once
# have any conversation (confirmed reply on screen), then /exit
find "$CLAUDE_CONFIG_DIR" -name '*.jsonl' # -> nothing
find ~/.claude/projects -newer /tmp/marker -name '*.jsonl' # -> nothing for that cwd
What Should Happen?
The transcript should be written to $CLAUDE_CONFIG_DIR/projects/<cwd-slug>/<session-id>.jsonl, as it is for headless runs with the same profile and for interactive runs with the default config.
Notes
- Possibly related to the session daemon:
sessions/<pid>.jsonregistry and daemon sockets live under/tmp/cc-daemon-<uid>/, and the daemon appears to be per-default-config. The v2.1.208 release notes mention daemon fixes, but this still reproduces on 2.1.208. - Impact: every multi-profile setup using the
CLAUDE_CONFIG_DIRpattern (as recommended in #261) silently loses all interactive history/resume for those profiles.
3 Comments
Tried to reproduce on 2.1.233 (Linux, tmux): fresh
CLAUDE_CONFIG_DIR=/tmp/cc-alt, interactive session, 2 prompts,/exit— the transcript was written to$CLAUDE_CONFIG_DIR/projects/<cwd-slug>/<session-id>.jsonl, and--resumefinds it. Same forclaude -p. So a customCLAUDE_CONFIG_DIRby itself doesn't cause this.Your exact symptom (interactive writes no transcript while
-pdoes, andshell-snapshots/etc. are still written) matches one specific intended behavior: an interactive session that inherits theCLAUDE_CODE_CHILD_SESSIONmarker (set in every subprocess a Claude Code session spawns) orCLAUDE_CODE_SKIP_PROMPT_HISTORYskips transcript saving so nested sessions don't pollute--resume; headless-pstill saves. These can leak in via a wrapper script, shell profile, or a tmux/screen server that was originally started from inside a Claude Code session. I verified on 2.1.233 that setting the marker reproduces your report exactly.Could you check in the shell where you launch the isolated profile:
env | grep -E 'CLAUDE_CODE_(CHILD_SESSION|SKIP_PROMPT_HISTORY)'(andtmux show-environment -g | grep CLAUDEif in tmux)If a var is set, unset it (or launch with
CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1) — see the session saving warnings docs. If neither var is set and you still lose transcripts on 2.1.233 with no warning shown, please reply with the output above and we'll dig further.🤖 Generated with Claude Code
We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected? This issue will be closed automatically if there's no activity within 7 days.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.