claude-code agent fails with nested session error in devcontainers

[martintburgess]

Environment

• roborev version: v0.31.1
• Claude Code version: 2.1.42
• OS: Linux (devcontainer)
• Agent: claude-code
• Command: roborev review

Problem

When running roborev review with the claude-code agent configured, all review jobs fail with:

agent: claude failed: exit status 1 (parse error: no valid stream-json events parsed from output)
stderr: Error: Claude Code cannot be launched inside another Claude Code session.
Nested sessions share runtime resources and will crash all active sessions.
To bypass this check, unset the CLAUDECODE environment variable.

This happens when roborev is run from a regular terminal (not within an active Claude Code session).

Verified:

• The CLAUDECODE environment variable is not set (echo $CLAUDECODE returns empty)
• No Claude Code process is running (ps aux | grep claude shows no active sessions)
• Running from a standard terminal in a devcontainer

Suspected root cause

roborev appears to be spawning Claude Code in a way that causes it to detect a nested session. This might be:

• Spawning claude multiple times in sequence
• Not properly cleaning up environment state between calls
• Some interaction with how roborev's worker pool manages Claude Code processes

Claude Code has guards against nested sessions that check more than just the CLAUDECODE variable - they may detect process hierarchy, sockets, or other runtime state.

Expected behaviour

roborev should be able to use the claude-code agent without triggering nested session errors, or should provide clear guidance on how to configure it properly for environments where the CLI approach won't work.

Suggested fix

This is my first time using roborev. Not sure if I have missed something but I wonder if something in roborev needs to be adjusted to avoid nesting sessions.

Related

• Claude Code nested session guard: [DOCS] Session docs missing nested-Claude launch guard behavior and recovery guidance anthropics/claude-code#25434

[cderv]

Confirming this also happens on Windows (not just devcontainers).

Environment:

• roborev v0.31.1
• Claude Code 2.1.42
• Windows 11

Reproduction

The daemon is started (or reviews are triggered via post-commit hooks) while a Claude Code session is active. Claude Code sets a CLAUDECODE environment variable, and child processes inherit it. When workers spawn claude for reviews, Claude Code sees CLAUDECODE and refuses to start.

In my case, jobs 145-148 succeeded (daemon running before Claude Code was opened), but jobs 149-152 all failed — triggered by post-commit hooks while working inside a Claude Code session:

$ roborev status
Recent Errors (last 24h): 4
  [16m0s ago] worker: job 152 - job 152 failed after 3 retries: agent: claude failed: exit status 1 (parse error: no valid stream-json events parsed from output)
stderr: Error: Claude Code cannot be launched inside another Claude Code session.
Nested sessions share runtime resources and will crash all active sessions.
To bypass this check, unset the CLAUDECODE environment variable.

Restarting the daemon from a terminal outside Claude Code resolves it (until the next hook-triggered restart inherits the env var again).

Root cause

This is the same class of issue as #230 (daemon inheriting GIT_DIR from hooks). In internal/agent/claude.go around line 139-144, the environment is built from os.Environ() filtered only for ANTHROPIC_API_KEY:

cmd.Env = filterEnv(os.Environ(), "ANTHROPIC_API_KEY")

The CLAUDECODE variable passes through to the child process, triggering the nested session guard that Claude Code added in v2.1.39.

Suggested fix

We could strip CLAUDECODE from the environment when spawning claude. One approach would be to make filterEnv variadic and add CLAUDECODE to the filter:

func filterEnv(env []string, keys ...string) []string {

// then at the call sites:
cmd.Env = filterEnv(os.Environ(), "ANTHROPIC_API_KEY", "CLAUDECODE")

This mirrors the fix for #230 where GIT_DIR was stripped from the daemon spawn environment.

[wesm]

Thanks. I will look at this and patch it today

[wesm]

This is fixed in main now I believe — I'm working on finalizing another PR but I will plan to cut 0.32.0 soon after that

[martintburgess]

Thanks for the quick fix @wesm !!