Marketplace plugin agents silently de-register on session resume when the marketplace is auto-updating; no re-registration path for the rest of the session

Summary

When a session is resumed into a new CLI process (daemon resume / --resume) while the plugin marketplace that supplies custom agents has a freshly published version (auto-update in flight), the agent registry built at process startup can omit every agent from that marketplace — even plugins in the marketplace whose own version did not change, and even though all agent definition files exist on disk in the plugin cache. The registry never recovers for the life of the session: MCP servers that drop at the same moment reconnect and re-add their tools minutes later, but there is no equivalent re-scan for plugin agents. Any Task/Workflow agent() call naming the de-registered agentType then hard-fails:

Error: agent({agentType}): agent type 'architect2:eng-builder' not found.
Available agents: claude, claude-code-guide, Explore, general-purpose, Plan,
statusline-setup, vercel:ai-architect, vercel:deployment-expert, vercel:performance-optimizer
    at G (/$bunfs/root/src/entrypoints/cli.js:4369:4946)
    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:2497:239)

Environment

• Claude Code CLI 2.1.196, Linux (Ubuntu, Hetzner VM), root user, daemon/background session (--resume)
• Marketplace: the-human-stack, source git@github.com:thehumanstackteam/the-human-stack-plugins (SSH), autoUpdate: true
• Plugins from that marketplace registering agents: architect2 (agents architect2:architect, architect2:eng-builder, ...) and exec-team (exec-team:ceorchestrator, exec-team:vp-*)
• Control group present in the same session: built-in agents, claude-plugins-official, and a vercel marketplace (no fresh publishes at the time)

Timeline (from session transcripts; all times UTC, 2026-06-30)

1. 14:13:06 — fresh session starts. agent_listing_delta shows all 14 the-human-stack agents added (architect2:* + exec-team:*) alongside built-ins and vercel:*. Plugin architect2 cache active at 1.6.x.
2. 14:16:17 — the marketplace publishes architect2 1.7.0 (commit a580c14e bumps plugin.json + marketplace.json from 1.6.4). No other marketplace in the install has anything new to pull.
3. 14:32:46 — the conversation is resumed into a new daemon process (MCP log directories show a new process fingerprint at exactly 14:32:46).
4. 14:32:48.082 — one attachment batch in the resumed transcript:

• deferred_tools_delta: −259 claude.ai connector tools (Descript, Fathom, GitHub, ...)
• mcp_instructions_delta: −2 (Descript, Fathom)
• agent_listing_delta: removed all 14 the-human-stack agents; added none. Built-in + official + vercel:* agents all survive.

1. 14:33:18.140 — MCP servers finish reconnecting: deferred_tools_delta +190, mcp_instructions_delta +2. No agent_listing_delta accompanies the reconnect — the agents stay gone. No further agent delta appears for the rest of the session.
2. ~14:36 — a workflow run (wf_b43dd340-88b) spawning agentType: 'architect2:eng-builder' fails in ~21 ms with the error above. Recovery required hand-patching the run to general-purpose, losing the specialized agent system prompts.
3. 15:23 (post-incident inspection, same session) — cache dirs for architect2 1.4.0 through 1.7.0 all present on disk with intact agents/*.md; the marketplace clone also intact. So the files were never missing — the registry simply omitted them.

Analysis

• The de-registration is scoped to exactly one marketplace, not one plugin: exec-team had no version change (installed 0.2.1, untouched since 2026-06-10) and dropped anyway, while vercel (different marketplace, nothing to update) survived. This points at the marketplace-level enumeration/update path at process startup, not at any individual plugin's manifest.
• The only distinguishing state of the failing marketplace at that startup: a version publish 16 minutes earlier, so its auto-update had real work to do (git pull over SSH + install of the new version + rewrite of installed_plugins.json) exactly while the new process was building its agent registry. The registry build appears to race the marketplace update and, on losing, skips the marketplace's plugins wholesale.
• The same transcript contains a natural control for the "MCP reconnect causes it" theory: an MCP disconnect/reconnect cycle did occur (14:32:48 → 14:33:18) and restored tools + instructions — but never touched the agent listing. Agent registration has no reconnect/repair path.
• Silent failure: the only user-visible signal is a passive "The following agent types are no longer available" notice in the resumed conversation; nothing indicates a marketplace scan failure, and no error is logged anywhere we could find on the host.

Asks

1. Atomic/deferred registry build vs. marketplace updates — at process start, either complete (or skip) the in-flight marketplace update before scanning agents, or scan from the last-known-good installed state; never half-read a marketplace mid-install.
2. A re-scan/heal path for plugin agents — MCP servers reconnect; plugin agents should have an equivalent (periodic re-scan, re-scan on agent type not found, or a manual command) instead of a session-lifetime dead registry.
3. Loud failure — when a marketplace or plugin fails the startup agent scan, log the actual error (auth, lock, parse, race) somewhere inspectable; the current silence made root-causing this require transcript archaeology.

Downstream mitigation already shipped (for context)

The plugin now threads an agent-fallback helper through its workflow agent() call sites (fall back to general-purpose with the agent's system prompt inlined when the typed agent is unregistered) — thehumanstackteam/ths-architect#242. That converts the hard failure into a degraded run but cannot restore the specialized agent definitions the registry lost.