Context
Phase 3 follow-up from #160 — Concrete PR D (optional, self-contained).
Scope
- This one touches probe internals so may prefer to handle in-house
- Pattern:
activeProbe selection keyed by account ID instead of probe mode, per-account snapshots stored in a dictionary, switchAccount changes the active probe
- Each account maps to a CLI profile (
claude --profile work) or API token env var via probeConfig
Notes
The existing ClaudeProvider already has dual probe support (CLI + API). Multi-account extends this to N probes, one per account. The activeProbe selection logic already exists — it just needs to be keyed by account ID instead of probe mode.
Dependencies
Depends on PR A (#164) and PR B for full functionality.
Ref: #160 (Phase 3 discussion in PR comments)
Context
Phase 3 follow-up from #160 — Concrete PR D (optional, self-contained).
Scope
activeProbeselection keyed by account ID instead of probe mode, per-account snapshots stored in a dictionary,switchAccountchanges the active probeclaude --profile work) or API token env var viaprobeConfigNotes
The existing
ClaudeProvideralready has dual probe support (CLI + API). Multi-account extends this to N probes, one per account. TheactiveProbeselection logic already exists — it just needs to be keyed by account ID instead of probe mode.Dependencies
Depends on PR A (#164) and PR B for full functionality.
Ref: #160 (Phase 3 discussion in PR comments)