fix: unset CLAUDECODE env var when spawning worker daemon from hooks

[Blevene]

Summary

• Wraps all 4 worker-service.cjs start hook commands with env -u CLAUDECODE to prevent the worker daemon from inheriting the Claude Code session environment variable

Problem

Hook commands run inside Claude Code's process tree, so bun worker-service.cjs start inherits the CLAUDECODE environment variable. This causes the worker daemon to behave as if it's running inside a Claude Code session, interfering with subprocess spawning in nested environments.

Related: #1163 (broader env-leaking issue with CLAUDECODE, CLAUDE_CODE_ENTRYPOINT, proxy vars)

Test plan

• Start a Claude Code session, verify worker-service.cjs spawns
• Check the worker process environment: cat /proc/<pid>/environ | tr '\0' '\n' | grep CLAUDE — verify CLAUDECODE is not set
• Verify worker functionality is unaffected (search, observations, etc.)

Fixes #1352

🤖 Generated with Claude Code

[xkonjin]

Code Review

This PR addresses an environment variable issue by unsetting CLAUDECODE before spawning the worker daemon from hooks. This prevents potential configuration leaks.

What's Good

• Targeted fix: addresses the root cause without unnecessary changes
• Consistent application across all hook configurations (workspace, agent, chat, server)
• Uses standard env -u which is portable and well-understood

Considerations

Documentation

• The PR description doesn't explain why CLAUDECODE needs to be unset. Consider adding what problems occur if CLAUDECODE is inherited and why this matters for the worker daemon specifically.

Error Handling

• If env -u fails (unlikely but possible), the command won't run at all. Consider whether the worker should still start even if unsetting the variable fails.

Alternatives

• Could also consider using CLAUDECODE="" bun ... which explicitly sets it to empty instead of removing it from the environment entirely. However, env -u is cleaner if the intent is to completely remove it.

Testing

• Verify that the worker daemon starts correctly with this change
• Test that CLAUDECODE is actually unset in the worker process
• Ensure hooks still function as expected after this change

Summary

LGTM with the above considerations addressed. This is a clean fix that prevents environment variable leakage. Adding documentation to explain the rationale would make the PR more self-contained and help future maintainers understand the change.

Status: Looks good, suggest adding rationale to PR description

[xkonjin]

Code Review — Unset CLAUDECODE env var in hooks

Overall: Targeted, low-risk fix. The diagnosis is correct — hook commands inheriting CLAUDECODE from the parent Claude Code session would cause the worker daemon to misidentify its execution context.

✅ Strengths

• Minimal diff, surgical fix across all 4 hook invocations
• env -u CLAUDECODE is POSIX-compliant and reliable
• Correctly addresses the root cause rather than working around it in worker-service.cjs

🟡 Portability concern

env -u works on Linux and macOS but is not available on Windows (even in Git Bash). If any users run Claude Code hooks on Windows, this will break. Depending on the user base, a cross-platform alternative in worker-service.cjs itself (e.g. delete process.env.CLAUDECODE at startup) might be more robust.

💡 Suggestion: add a comment

Since the env -u prefix is non-obvious, a one-line comment in hooks.json (if JSON5/comments are supported) or in the PR description explaining why would help future maintainers. The PR description already covers this well, so this is mainly for discoverability.

[thedotmack]

Superseded by the embedded Process Supervisor (PR #1370, v10.5.6). Env sanitization is now centralized in src/supervisor/env-sanitizer.ts — strips all CLAUDECODE_*, CLAUDE_CODE_*, and related vars before spawning any subprocess.