Headless `claude -p` session under a secondary CLAUDE_CONFIG_DIR login can't attach claude.ai connectors, even though the same account's connectors work fine interactively

Summary

We run an automation setup where a single Windows host authenticates as two separate Claude accounts via CLAUDE_CONFIG_DIR: a primary Team/Enterprise seat (default config dir) for the main scheduled workload, and a personal Pro/Max seat under a dedicated CLAUDE_CONFIG_DIR (created via claude /login in an isolated browser session) used only as a fallback when the primary seat hits a usage/spend limit. Both accounts have claude.ai connectors configured (Microsoft 365, Fireflies, etc.) and both were confirmed working when set up.

As of some point between two consecutive days last week, headless (-p/--print, non-interactive) sessions run under the secondary/personal CLAUDE_CONFIG_DIR stopped being able to see any connector tools at all, while everything else about that identity is fine.

Reproduction

$env:CLAUDE_CONFIG_DIR = 'C:\path\to\personal-config-dir'
& claude.exe -p "Call ToolSearch query <connector-name> (max 10). If found, call <a tool from that connector> and reply IDENTITY <email>. If absent after 3 ToolSearch attempts reply TOOLS-ABSENT. No other action." --output-format text

Expected: the connector tool is found and returns the expected identity/data.
Actual: ToolSearch returns nothing for the connector across multiple retries (including a realistic warm-up — reading a couple of files before searching), and the session reports the tools are absent.

What we ruled out

• Not stale credentials. Re-ran claude /login for this account shortly before testing; confirmed via the config dir's stored auth that the correct account is present (right email, right plan tier) — the login itself is valid and fresh.
• Not a CLI version issue. Reproduced on two consecutive patch versions (upgraded mid-investigation); failed on both before and after the upgrade, so the version bump isn't the cause.
• Not an account-wide connector problem. The exact same personal account, used interactively (normal desktop app session, not headless) on a different machine, successfully uses the same connector all day.
• Not "headless can't use connectors" in general. The primary Team/Enterprise seat on the same automation host, invoked the same way (claude -p, non-interactive, scheduled task), successfully uses its claude.ai connectors every day without issue. Only the secondary/personal-seat headless path is affected.
• claude mcp list is not a useful diagnostic here — as of the newer CLI version it no longer lists claude.ai connectors at all under either config dir, connected or not. We confirmed the real signal (connector tools present/absent) via ToolSearch inside a live session instead, which the account's actual connector state should still surface correctly if attached.

Timeline

• Confirmed working (headless, this exact config-dir pattern, this exact connector): morning of day 0.
• Confirmed broken: evening of day 1 (roughly 30 hours later), no configuration change made on our end in between.
• Re-tested 6 days after first noticing: still broken, same TOOLS-ABSENT result — so this isn't transient/flaky, it's a persistent state change.

Environment

• Claude Code CLI, two consecutive recent patch versions (upgrade happened mid-investigation, didn't change the outcome)
• Windows Server, invoked via a scheduled task / non-interactive PowerShell session (no TTY)
• Two CLAUDE_CONFIG_DIRs on one host: a default/primary Team seat and a secondary personal Pro/Max seat set up via claude /login (browser-based, InPrivate window to avoid SSO session reuse with the primary account)

Question for the team

1. Is connector attachment for a secondary/non-default login in a headless session an intentional restriction, or is this a regression?
2. If intentional, is there a supported pattern for "primary seat is temporarily over its usage limit, fall back to a second identity that still has working connectors" in headless/automation contexts? Right now we have no reliable way to keep connector-backed automation running when the primary seat's limit is hit.

Happy to provide more reproduction detail or run additional diagnostics if useful.