[BUG] claude.ai connectors not registered at session start in task-chip-spawned sessions; appear only mid-session as UUID servers, while plugin:productivity:* keeps claiming they need auth

Summary

In a session opened from a background task chip generated by a previous session (running in a git worktree), the claude.ai connectors (Sentry, Linear, Notion, Slack, Gmail, Figma, PostHog) are not registered at session start. They are absent from the deferred-tool listing, mcp-registry list_connectors returns an empty set, and ToolSearch cannot find them by product name — so the model correctly concludes the capability does not exist and reports it as unavailable.

The connectors then appeared mid-session, immediately after I opened the Connectors menu in the UI, registered as UUID-named MCP servers (mcp__8e73e321-…__* = Sentry, mcp__9f10a12c-…__* = Linear, etc.). They worked on the first call.

Separately and compounding it: the same system reminder that omitted the real connectors advertised plugin:productivity:linear, plugin:productivity:notion, plugin:productivity:slack, plugin:productivity:asana, plugin:productivity:atlassian, plugin:productivity:clickup, plugin:productivity:monday as requiring authentication — and it still lists them as requiring authentication now, after the real Linear/Notion/Slack connectors are live and working. So there appear to be two parallel registrations of the same products, and the stale "needs auth" notice keeps instructing the model to tell the user to go authorize things that already work.

This session's connectors are the same set the originating session had working. Nothing was authorized in between.

Impact

This is not just a nuisance — it silently produced a wrong engineering conclusion.

The task was to check Sentry for low-rate MySQL 1205 / TransportException occurrences across four consumers, then decide whether to widen a deploy-time mitigation.

1. Sentry appeared unavailable, so I fell back to CloudWatch Logs Insights.
2. CloudWatch retention on those log groups is 30 days. Within that window the evidence was unambiguous: 16,350 lock-wait crashes, 100% on one consumer, zero on the other three.
3. I recommended not widening the mitigation, and wrote up that recommendation with an evidence table.
4. Once the Sentry connector appeared, the first query overturned it: a second Sentry issue (25,008 occurrences, last seen 36 days ago — just outside CloudWatch retention) showed the same class of lock contention crashing a second consumer, as MySQL 1213 deadlocks rather than 1205. The correct recommendation was the opposite of what I'd written.

So the failure mode is: the model doesn't know a data source exists, substitutes a shallower one, and reports a confident conclusion that the missing source would have contradicted. The user has no signal that this happened.

Wasted effort in this session: roughly a dozen CloudWatch Insights queries and a full written analysis, plus the user's time reading a recommendation that had to be retracted.

What Was Investigated

Before concluding the connector was unavailable, I checked four ways:

1. ToolSearch — "sentry error tracking issues" → no Sentry tools.
2. ToolSearch — "+sentry" (require the token in the tool name) → No matching deferred tools found.
3. ToolSearch — "issue stacktrace crash exception monitoring alerts organization project" → returned Monitor, DesignSync, LaunchDarkly, mcp-registry; no Sentry.
4. mcp-registry list_connectors with keywords: ["sentry"] → {"connectors":[],"note":"No installed connectors found — the card did not render."}

I also checked ~/.claude.json, which records claudeAiMcpEverConnected: ["claude.ai Slack", "claude.ai Gmail", "claude.ai Linear", "claude.ai Notion", "claude.ai Sentry", "claude.ai Mermaid Chart", "claude.ai Figma"] — so the client knows these connectors by friendly name while the live session registers them under opaque UUIDs.

After the connectors appeared, find_organizations returned on the first try — no auth step, no retry.

Secondary issue: UUID server names defeat tool search

Because the servers are named by UUID rather than by product, keyword search cannot find them by product name. For the Sentry server, only 2 of ~10 tools contain "sentry" in the tool name (execute_sentry_tool, search_sentry_tools); the ones you'd actually reach for are find_organizations, search_issues, search_events, get_sentry_resource. A +sentry name-filtered search therefore misses the useful tools even when the server is registered. Product name as a searchable alias on the server would fix this independently of the registration bug.

Expected Behavior

1. A session spawned from a task chip should have the same connector set registered at startup as the session that generated the chip — without requiring the user to open the Connectors menu.
2. If connectors genuinely cannot be registered at startup, the session should say so in a way the model can act on ("connectors pending, retry shortly") rather than presenting an environment where they simply do not exist. Silent absence is what converts into wrong answers.
3. The plugin:productivity:* "requires authentication" notice should not be emitted for a product whose claude.ai connector is already registered and working — and it should stop being emitted once registration happens mid-session.
4. Connector MCP servers should be discoverable by product name in ToolSearch, not only by UUID.

Repro

1. In session A, with claude.ai connectors working, spawn a background task chip.
2. Open that chip as a new session (mine was in a git worktree under .claude/worktrees/).
3. In the new session, ask for something that requires a connector — e.g. "check Sentry for errors matching X".
4. Observe: no connector tools in the deferred-tool listing; list_connectors returns empty; ToolSearch finds nothing; the model reports the connector unavailable and suggests authorizing it.
5. Open the Connectors menu in the UI (all connectors show enabled).
6. Observe: connector tools arrive mid-turn as UUID-named servers and work immediately, while the plugin:productivity:* auth-required notice persists in the same reminder.

I can't prove opening the menu is what triggered registration — I only observed that the tools arrived in the next system reminder after I did it, having been absent for many turns before. Worth checking whether registration is lazy/UI-triggered or just slow.

Environment

• Claude Code 2.1.177
• macOS 26.5.1 (build 25F80), Darwin 25.5.0, arm64
• Model: Opus 5 (session started on Fable 5, switched mid-session with /model; the connector absence spanned both)
• Session was in a git worktree (.git is a file → gitdir: …/.git/worktrees/quirky-diffie-89ef6f)
• Locally-configured MCP servers (present and working the whole time): LaunchDarkly, posthog
• Connector servers that appeared late, by UUID: 8e73e321-… (Sentry), 9f10a12c-… (Linear), b30d415d-… (Notion), 8335f724-… (Slack), 86003b1e-… (Gmail), 8f0a46f6-… (Figma), 486278b0-… (PostHog)

Context

This is the second issue I've filed about sessions spawned from task chips/shards behaving differently from their originating session — see #69161 (CI-monitor branch subscriptions leaking between a shard-spawned session and its parent). The pattern across them is that the spawned session doesn't cleanly inherit the parent session's context/config, and this one is the most damaging so far because it degrades answer quality rather than just ergonomics.