Bridge session registration (bridgeSessionId) broken in v2.1.132 — regression from v2.1.131

Environment

• Claude Code version: 2.1.132 (regression from 2.1.131)
• OS: macOS (arm64)
• Auth method: OAuth (claude.ai)
• Subscription: Max (subscriptionType: max)

Bug description

Every new Claude Code session started with v2.1.132 fails to register with the remote control bridge service. Sessions display "Claude API" mode on startup instead of the Max subscription mode, and remote control (viewing/controlling sessions from claude.ai) does not work.

Running claude auth login from _within_ an already-active session temporarily fixes bridge registration for that session only. It does not persist — the next new session is broken again.

Steps to reproduce

1. Start a new session with v2.1.132: claude
2. Check ~/.claude/sessions/<pid>.json — bridgeSessionId field is absent
3. Session shows "Claude API" mode in startup banner
4. Session does not appear under remote control in claude.ai

Expected vs observed

v2.1.131 session files contain a bridgeSessionId field:

{
  "pid": 22597,
  "version": "2.1.131",
  "bridgeSessionId": "session_01[REDACTED]",
  ...
}

v2.1.132 session files are missing this field entirely:

{
  "pid": 11942,
  "version": "2.1.132"
}

This is consistent across all sessions observed: every v2.1.131 session registered a bridge session ID; no v2.1.132 session has.

Auth state

claude auth status correctly reports the account:

{
  "loggedIn": true,
  "authMethod": "claude.ai",
  "subscriptionType": "max"
}

However, ~/.claude.json contains stale/unrefreshed cache fields that do not update on session startup in v2.1.132:

| Field | Value |
|---|---|
| oauthAccount.seatTier | null |
| hasAvailableSubscription | false |
| clientDataCache | null |

These fields appear to be populated correctly during an interactive claude auth login flow (explaining the per-session workaround) but are not refreshed on normal session startup.

The account has billingType: stripe_subscription — possibly an older Max subscription that predates the seatTier concept, resulting in the server returning seatTier: null. It's unclear whether v2.1.132 introduced a seatTier gate on bridge registration, or whether the startup account-data refresh that populates it was broken.

Workaround

Downgrading to v2.1.131 restores normal bridge registration:

ln -sf ~/.local/share/claude/versions/2.1.131 ~/.local/bin/claude