[BUG] Background sessions don't load user agents from ~/.claude/agents/ into the Agent tool registry (related: #41973, #58353)

Status Fixed / completed
Reported on v2.1.140
Maintainer reply ✓ Yes — bogini
Activity 5 comments · opened May 13, 2026 · closed May 27, 2026
💡 Likely answer: A maintainer (bogini, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues — closest are #41973 (same symptom in mcp serve mode) and #58353 (same bg session mode, different missing feature). This is the intersection — bg sessions specifically failing to load user agents.
  • [x] This is a single bug report.
  • [x] I am using the latest version of Claude Code (2.1.140).

What's wrong

Background sessions (i.e. anything spawned by claude daemon / launched as a bg job from an interactive session or from FleetView) expose a different Agent-tool registry than the rest of Claude Code reports for the same user.

  • claude agents from any shell correctly reports user agents in ~/.claude/agents/ (3 user + 5 built-in = 8 total).
  • Inside a bg session, attempting subagent_type: "<user-agent-name>" via the Agent tool is rejected with:

``
Agent type 'utility-bot' not found. Available agents: claude, claude-code-guide, Explore, general-purpose, Plan, statusline-setup
`
Note: the "Available agents" list is **different** from what
claude agents reports — it includes claude-code-guide (not in claude agents`) and excludes all three user agents.

Effect: any bg-session work that should be routed to a user-defined model-specific agent (e.g. utility-bot → Haiku for docs, developer → Sonnet for code) silently falls back to general-purpose, which defaults to the main session's model (Opus in my case). Result: routine bg work runs on Opus when it should run on Haiku or Sonnet — quietly burning budget.

Hard evidence of the divergence

From the same shell, same user, same machine:

$ claude agents
8 active agents

User agents:
  developer · sonnet
  plan · opus
  utility-bot · haiku

Built-in agents:
  claude · inherit
  Explore · haiku
  general-purpose · inherit
  Plan · inherit
  statusline-setup · sonnet

From inside a bg session, attempting Agent with any user-agent name:

Agent type 'utility-bot' not found. Available agents: claude, claude-code-guide, Explore, general-purpose, Plan, statusline-setup

Differences:

  • Bg session sees claude-code-guide — claude agents doesn't list it.
  • Bg session does NOT see developer, utility-bot, plan (the user agents).

What should happen

bg sessions should merge ~/.claude/agents/ into the Agent-tool runtime registry the same way interactive sessions do. If that's intentionally divergent for some reason, the behaviour should at least be documented and the claude agents CLI output should match what bg sessions actually see.

Workarounds tried (all failed)

  1. settings.json:agents key — REJECTED by schema validator:

``
Unrecognized field: agents. Check for typos or refer to the documentation for valid fields
`
The schema's top-level
additionalProperties: {} is overridden by a strict validator. Only agent` (singular, string) is accepted.

  1. subagent_type resolved by name only — confirmed deterministic rejection on every invocation. No retry/refresh path from inside the bg session.
  1. --agents '<json>' — Per #41973 the same flag also fails to fix the analogous bug in mcp serve mode. I have not personally retested for bg, but the user reports for #41973 align with the symptom.

Suggested fix

In the bg session-template boot path (the code that builds options.agentDefinitions.activeAgents), apply the same ~/.claude/agents/ + project .claude/agents/ discovery that claude agents and interactive sessions already use. The disk-level discovery clearly works (proven by claude agents); only the bg template's wiring of that discovery into the Agent tool resolver is missing.

Concrete repro

  1. Add ~/.claude/agents/utility-bot.md:

``markdown
---
name: utility-bot
description: Fast, low-context tasks (commit messages, doc updates, formatting).
model: haiku
---
You are the Utility Bot...
``

  1. Confirm the CLI sees it: claude agents → shows utility-bot · haiku under "User agents".
  2. From an interactive session, spawn a bg session (any FleetView/slash flow that triggers claude daemon run --origin transient).
  3. In the bg session, call the Agent tool with subagent_type: "utility-bot".
  4. Observe: Agent type 'utility-bot' not found. Available agents: claude, claude-code-guide, Explore, general-purpose, Plan, statusline-setup.

Environment

  • Claude Code Version: 2.1.140
  • Platform: macOS (Darwin 25.5.0)
  • Process tree: bg agent under claude daemon ... --origin transient --spawned-by "slash"
  • state.json: "template": "bg", "sessionKind": "bg" in the session's JSONL records.
  • Env: CLAUDECODE=1, CLAUDE_JOB_DIR=~/.claude/jobs/<id>.

Related

  • #41973 — Same root cause class for mcp serve mode (also non-interactive, also strips user agents from the Agent-tool registry).
  • #58353 — Same bg session-mode environmental stripping, but for Claude.ai remote connectors instead of user agents. Strongly suggests the broader fix is "bg-template environment parity with interactive".

View original on GitHub ↗

5 Comments

github-actions[bot] · 5 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/41973

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

bogini collaborator · 5 months ago

Thanks for the report and the repro — confirmed. The agent loader had a catch-all that dropped everything (including your ~/.claude/agents/ definitions) to built-ins-only if any sub-loader threw, and the plugin loader can throw in daemon-spawned workers. Fixed: each loader now fails independently, so a plugin-loader error no longer drops your custom agents.

Ships in v2.1.142. Appreciate you linking #41973/#58353 — same init-path-gap class, helped narrow it fast.

kcarriedo · 5 months ago

The registry-divergence symptom + the budget-silent-burn consequence together is one of the more insidious failure modes I've seen in the Agent Teams surface. The fact that claude agents (the diagnostic CLI) and the bg-session-resident Agent tool registry are reading from different sources means the operator's mental model and the runtime's behavior have diverged before any work even starts.

This pairs unfortunately with #54018 and #54879 — both also "subagent dispatch silently degrades" patterns. Together they describe a category: the subagent runtime contract is not the same across spawn paths. Foreground/interactive sees one set of teammates, claude daemon sees another, async-loop sees yet another. Operators who write fleet code against the foreground contract get a different runtime when they background-detach.

For the "Opus when it should be Haiku" budget-burn part specifically: a claude daemon-shape user's whole reason to define a Haiku-model utility-bot is cost containment for long-running async work. When the bg session silently falls back to the default-model general-purpose agent, the user is now paying ~10× per token for the exact workload they explicitly engineered around — and the only signal is the monthly bill.

Two thoughts on hardening:

  1. The "agent type not found" rejection ought to itemize which registry was consulted (~/.claude/agents/, project-local, daemon-context, etc.) so the divergence is debuggable from a single error message rather than requiring a claude agents cross-check.
  2. If FleetView's bg-session path uses a separate registry-load codepath at all, the symmetry-test (interactive-list == bg-list for the same user/project) seems like a cheap CI assertion to wire up.

Subscribing — same shape of issue blocks any production fleet that splits work between interactive PM and background workers.

bogini collaborator · 4 months ago

Addressed by a merged fix. Please reopen with a fresh repro if you still see this on a current version.

github-actions[bot] · 2 months ago

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.