Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   platform:linuxIssue specifically occurs on LinuxIssue specifically occurs on Linux

   area:tools

   area:core

   on Feb 10, 2026
2. github-actions commented on Feb 10, 2026

   

   github-actionsBot

   on Feb 10, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. [BUG] CLAUDE_ENV_FILE not sourced on resumed sessions (--continue) #12418
   2. [BUG] CLAUDE_ENV_FILE not sourced after /clear creates new session #14433
   3. CLAUDE_ENV_FILE not provided to SessionStart hooks #15840

   This issue will be automatically closed as a duplicate in 3 days.

   • If your issue is a duplicate, please close it and 👍 the existing issue instead
   • To prevent auto-closure, add a comment or 👎 this comment

   🤖 Generated with Claude Code

   👎React with 👎2Reacted by Gili Tzabari and Zrowsdower
3. cowwoc commented on Feb 10, 2026

   

   cowwoc

   on Feb 10, 2026

   Author

   More actions

   This is not a duplicate of any of the three linked issues. Here's why:

   #15840 — Reports CLAUDE_ENV_FILE being an empty string. Our CLAUDE_ENV_FILE is correctly set and non-empty. Different bug.

   #12418 — Describes the same symptom (env vars not available on resume) but was closed as a duplicate of #11649, which was about plugin hooks not receiving CLAUDE_ENV_FILE at all. Our issue identifies a different root cause: the session ID mismatch between hook execution time and env file loading time. #12418 never identified this root cause, and closing it as a duplicate of #11649 didn't fix the resume case.

   #14433 — Reports the same underlying mechanism but for /clear, not resume. Related but a different trigger with potentially different fix paths.

   What makes this issue distinct:

   This report identifies the specific root cause with evidence from the compiled binary source: R$() returns the startup session ID when CLAUDE_ENV_FILE paths are generated for hooks, but returns the resumed session ID when ybI() reads env files for Bash tool calls. The env files are written to session-env/STARTUP_ID/ but read from session-env/RESUMED_ID/. The evidence section in the issue body shows the exact session IDs and directory paths demonstrating the mismatch.

   None of the linked issues identify this root cause.

   👍React with 👍1Reacted by Zrowsdower
4. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Feb 24, 2026
5. Zrowsdower commented on Feb 27, 2026

   

   Zrowsdower

   on Feb 27, 2026

   Last edited by Zrowsdower

   More actions

   Confirming this bug independently on macOS (arm64), Claude Code 2.1.62. @cowwoc's root cause analysis is correct — the session ID mismatch is the core issue.

   Additional finding: the cache invalidation is independent

   @cowwoc noted the caching in ybI() as a "secondary concern." We've confirmed it's actually an independent issue that affects different scenarios:

   Scenario	Directory mismatch?	Cache stale?	Result
   Fresh start	No	No	Works
   /clear or compact	No	Yes (without async signal)	Stale
   --resume / --continue	Yes	Yes (without async signal)	Stale
   --resume + async signal only	Yes	No	Still stale

   The cache invalidation function (RbI()) works correctly — but it's only called in the async hook completion path. Sync hooks (the default shown in docs) never trigger it.

   The fix for the cache issue: Output {"async": true} to stdout from your SessionStart hook. This triggers the async completion path where RbI() lives. This alone fixes /clear and compact — but does NOT fix resume, because even after cache invalidation, ybI() re-reads from the resumed session's directory (which hooks never wrote to).

   Working workaround for resume

   We ship a plugin that depends on CLAUDE_ENV_FILE for CLI PATH injection. After isolating the two issues, we implemented a broadcast workaround:

   # After writing to our own CLAUDE_ENV_FILE, broadcast to ALL session-env dirs.
   # On resume, R$() returns a different session ID — ybI() reads from the original.
   # Overwriting all dirs ensures the original gets our PATH.
   EXPORT_LINE='export PATH="'"$PLUGIN_BIN"':$PATH"'
   for dir in "$HOME/.claude/session-env"/*/; do
     [ -d "$dir" ] || continue
     for f in "$dir"sessionstart-hook-*.sh; do
       [ -f "$f" ] || continue
       if grep -q "TOOL_NAME_HERE" "$f" 2>/dev/null; then
         printf '%s\n' "$EXPORT_LINE" > "$f"
       elif ! grep -q "$PLUGIN_BIN" "$f" 2>/dev/null; then
         printf '%s\n' "$EXPORT_LINE" >> "$f"
       fi
     done
   done

   This overwrites the PATH export in every ~/.claude/session-env/*/ directory on every SessionStart event. Combined with the async signal (to clear ybI()'s cache), resume reads correct data from the original directory.

   **This works for us and our setup, i'm not saying it won't break your setup if you utilize path injection for anything else.

   Summary

   • Directory mismatch (this issue): Real bug, no native fix. Broadcast workaround above.
   • Cache invalidation: Design gap — RbI() works via {"async": true} stdout, but this requirement is undocumented. Fixes /clear and compact independently of this issue.
   • These are independent — fixing either one alone doesn't fix all scenarios. Both must be addressed.

   👍React with 👍1Reacted by Zrowsdower
6. github-actions

   removed

   staleIssue is inactiveIssue is inactive

   on Feb 27, 2026
7. Zrowsdower commented on Feb 27, 2026

   

   Zrowsdower

   on Feb 27, 2026

   More actions

   Confirming this bug independently on macOS (arm64), Claude Code 2.1.62. @cowwoc's root cause analysis is correct — the session ID mismatch is the core issue.

   Additional finding: the cache invalidation is independent

   @cowwoc noted the caching in ybI() as a "secondary concern." We've confirmed it's actually an independent issue that affects different scenarios:

   Scenario Directory mismatch? Cache stale? Result
   Fresh start No No Works
   /clear or compact No Yes (without async signal) Stale
   --resume / --continue Yes Yes (without async signal) Stale
   --resume + async signal only Yes No Still stale
   The cache invalidation function (RbI()) works correctly — but it's only called in the async hook completion path. Sync hooks (the default shown in docs) never trigger it.

   The fix for the cache issue: Output {"async": true} to stdout from your SessionStart hook. This triggers the async completion path where RbI() lives. This alone fixes /clear and compact — but does NOT fix resume, because even after cache invalidation, ybI() re-reads from the resumed session's directory (which hooks never wrote to).

   Working workaround for resume

   We ship a plugin that depends on CLAUDE_ENV_FILE for CLI PATH injection. After isolating the two issues, we implemented a broadcast workaround:

   After writing to our own CLAUDE_ENV_FILE, broadcast to ALL session-env dirs.

   On resume, R$() returns a different session ID — ybI() reads from the original.

   Overwriting all dirs ensures the original gets our PATH.

   EXPORT_LINE='export PATH="'"$PLUGIN_BIN"':$PATH"'
   for dir in "$HOME/.claude/session-env"//; do
   [ -d "$dir" ] || continue
   for f in "$dir"sessionstart-hook-.sh; do
   [ -f "$f" ] || continue
   if grep -q "TOOL_NAME_HERE" "$f" 2>/dev/null; then
   printf '%s\n' "$EXPORT_LINE" > "$f"
   elif ! grep -q "$PLUGIN_BIN" "$f" 2>/dev/null; then
   printf '%s\n' "$EXPORT_LINE" >> "$f"
   fi
   done
   done
   This overwrites the PATH export in every ~/.claude/session-env/*/ directory on every SessionStart event. Combined with the async signal (to clear ybI()'s cache), resume reads correct data from the original directory.

   **This works for us and our setup, i'm not saying it won't break your setup if you utilize path injection for anything else.

   Summary

   • Directory mismatch (this issue): Real bug, no native fix. Broadcast workaround above.
   • Cache invalidation: Design gap — RbI() works via {"async": true} stdout, but this requirement is undocumented. Fixes /clear and compact independently of this issue.
   • These are independent — fixing either one alone doesn't fix all scenarios. Both must be addressed.

   Complete workaround architecture (for plugin authors)

   The broadcast snippet above is one layer of a four-layer workaround we developed for our plugin. Sharing the full picture since other plugin authors hitting this will need more than just the broadcast.

   The core problem for plugins

   Plugins that need a CLI on PATH face a compound issue: you need to know your current install path at hook execution time, but ${CLAUDE_PLUGIN_ROOT} (which hooks.json expands) goes stale when a plugin updates — Claude Code caches the old version's path at session start. On --resume, you're running a new version's hook but the session remembers the old version's paths.

   Layer 1: CPR (Current Plugin Root) resolver

   Instead of relying on ${CLAUDE_PLUGIN_ROOT} or SCRIPT_DIR (both go stale), read the current install path from Claude Code's own plugin registry:

   PLUGIN_KEY="your-plugin@your-marketplace"
   INSTALLED_PLUGINS="$HOME/.claude/plugins/installed_plugins.json"
   
   CURRENT_ROOT=""
   if [ -f "$INSTALLED_PLUGINS" ]; then
     CURRENT_ROOT=$(node -e "
       const data = JSON.parse(require('fs').readFileSync('$INSTALLED_PLUGINS','utf8'));
       const entries = data.plugins?.['$PLUGIN_KEY'] || [];
       if (entries.length > 0) console.log(entries[0].installPath);
     " 2>/dev/null || true)
   fi

   installed_plugins.json is updated by Claude Code on plugin install/update, so it always reflects the current version's path. This is plugin-specific — non-plugin tooling would need its own version sourcing (e.g., which, a known install path, or a version manager).

   Guard: If the CPR resolver fails (file missing, plugin not found), skip all PATH writes. Writing garbage like /bin to CLAUDE_ENV_FILE is worse than doing nothing.

   Layer 2: Overwrite (>) not append (>>)

   Use > (overwrite) when writing to CLAUDE_ENV_FILE, not >> (append). On /clear and compact, SessionStart fires again. Append accumulates stale entries across events; overwrite ensures only the current (CPR-resolved) path is present.

   Layer 3: Session-env broadcast

   This is the workaround for the directory mismatch described in the parent comment. After writing to your own CLAUDE_ENV_FILE, broadcast the same export to ALL ~/.claude/session-env/*/ directories. On --resume, ybI() reads from the original session's directory — the broadcast ensures it finds correct data there.

   Only overwrite files you own (grep for your plugin identifier to avoid clobbering other plugins' env files).

   Layer 4: Async signal + additionalContext

   cat <<EOF
   {"async": true, "hookSpecificOutput": {"hookEventName": "SessionStart", "additionalContext": "your-plugin root: ${CURRENT_ROOT}"}}
   EOF

   Two purposes:

   • "async": true triggers RbI() (cache invalidation) on hook completion, so ybI() re-reads from disk instead of serving cached startup data
   • additionalContext injects the current path into the model's system prompt as a backup channel — even if all env mechanisms fail, the model can see the correct path

   Why all four layers are needed

   Layer	What it fixes	Without it
   CPR resolver	Stale CLAUDE_PLUGIN_ROOT after plugin update	PATH points to old version's binaries
   Overwrite	Accumulated stale entries from repeated events	PATH grows with dead entries on every /clear
   Broadcast	Directory mismatch on --resume (this issue)	Correct data written to wrong dir, ybI() reads stale
   Async signal	RbI() never called for sync hooks	In-memory cache serves startup data forever

   Removing any single layer re-exposes a different failure mode. We verified this empirically across versions 1.6.0 through 1.6.9 of our plugin, adding one layer at a time and testing /clear, compact, and --resume at each step.

   Scope

   This workaround is specific to plugins that can read installed_plugins.json. Non-plugin tools using SessionStart hooks for PATH injection would need their own version sourcing for Layer 1, but Layers 2-4 apply universally to anyone writing to CLAUDE_ENV_FILE.
8. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Mar 14, 2026
9. github-actions commented on Mar 28, 2026

   

   github-actionsBot

   on Mar 28, 2026 – with GitHub Actions

   More actions

   Closing for now — inactive for too long. Please open a new issue if this is still relevant.
10. github-actions

    closed this as not plannedon Mar 28, 2026
11. github-actions

    removed

    staleIssue is inactiveIssue is inactive

    on Mar 28, 2026
12. github-actions commented on Apr 5, 2026

    

    github-actionsBot

    on Apr 5, 2026 – with GitHub Actions

    More actions

    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.
13. github-actions

    locked as resolved and limited conversation to collaborators on Apr 5, 2026