Repository navigation
[Bug]: Claude Code background agents (started by Claude Code, not Orca) inherit the parent pane's ORCA_PANE_KEY, so they never get their own sidebar row #34188
Description
Operating system
macOS (Darwin 25.6, arm64)
Orca version
1.4.237 · Claude Code 2.1.311
Details
Short summary. Claude Code can start background agents itself (its own job/daemon backend: the left-arrow "new agent" in Claude Code's agent view, /bg, etc.). When that happens from a Claude session running in an Orca pane, the new agent inherits the parent pane's ORCA_PANE_KEY, ORCA_TAB_ID, ORCA_WORKTREE_ID, ORCA_WORKSPACE_ID, ORCA_AGENT_HOOK_* and launch token. Orca's hook therefore reports the new agent's events under the parent pane's key, so the new agent never gets its own row in the sidebar. Its status merges into, or is overwritten by, the parent pane's row.
This looks like the same root cause as #26417, but on a path that the fix in #27204 can't reach: the child is started by Claude Code's background-job process, not by Orca, so Orca never builds its environment.
Steps to reproduce
- Open a Claude Code agent in an Orca pane (workspace A).
- In Claude Code, create a new background agent (left arrow → new agent in the agent view).
- Watch Orca's left sidebar.
Expected: a new agent row for the new session (or a child row under the parent).
Actual: no new row. Inside the new agent, env | grep ORCA_ shows 24 ORCA_* variables, and ORCA_PANE_KEY equals the parent pane's key. agent-hooks/last-status.json has no entry for the new session's session_id; the only entry for that pane key still carries the parent's providerSession.id. logs/daemon.log has no session-created for it, because Orca didn't start it.
Suggested fix (either side)
- In
claude-hook.sh/ the hook receiver: when a payload'ssession_iddiffers from the session already bound to thatpaneKeyand the child is a Claude Code background job (CLAUDE_JOB_DIR/CLAUDE_CODE_CHILD_SESSIONare set in its env), register it as a separate (child) agent row instead of folding it into the pane. - Or, when it's ambiguous, drop events whose
session_iddoesn't match the pane's bound session rather than overwriting the pane's state.
Activity
eatmoreduck commentedon Oct 27, 2026
Dug into the listener side to see what Orca can actually observe on this path, and there are two existing pieces that matter for scoping a fix:
Claude-job hook events are already declined on purpose.
ClaudeSessionContinuationTracker(src/shared/agent-hook-listener/claude-session-continuation.ts) documents that when Claude Code forks a pane's session into a daemon job, "that job's hooks are declined (fix(agent-hooks): stop backgrounded Claude sessions posting a stale pane key (STA-4769) #15304), so the pane's own transcript is the only evidence of where the conversation went." So for the/clear-style fork path, Orca deliberately does not trust hook events from the job and instead follows thecontinued-inrecord in the parent transcript to keep the pane row pointing at the live session (including thejobs/<id>/state.jsonvariant when/clearhappens inside the job).The open question for this issue's exact path is which of two failure modes you're seeing:
resolvePaneClaudeContinuationonly has one paneKey to work with.ORCA_PANE_KEY, that contradicts the decline decision and the fix is at the envelope/decline layer.Two things that would pin this down from your setup:
~/.claude/projects/<cwd slug>/<parent session>.jsonl) contain acontinued-inrecord naming the background agent's session id for the/bg/ agent-view new-agent path, the way it does for the fork path the tracker follows today?Not attempting a PR yet — which lever is correct depends on those answers, and re-shaping the pane-key→row model for child rows looks like a design change that belongs with the maintainers.