Tam Nhu Tran
839997d08e
Three substantive issues raised by upstream review, encoded in code +
spec so future drift can't reintroduce them:
1. Width floor was unenforceable. The previous spec wording said
"form ≥ 360px / json ≥ 320px" but `react-resizable-panels` v3 only
accepts percentage `minSize`. On a 1280px viewport this could let a
user drag a pane down to ~250px — well below the documented floor.
- `Panel minSize` bumped 25 → 30 (≥ 30% of body width after rail)
- Spec rewritten percent-based with the actual 300–360px range
across realistic viewports plus a note on the v3 API constraint
and the `onResize`-clamp escape hatch if hard pixel floors become
necessary later.
2. `storageKey` default caused cross-page state bleed. The previous
default `storageKey="ccs.config-layout"` meant any `<ConfigLayout>`
without an explicit key would share localStorage state with every
other Config page — split ratios contaminating across unrelated
pages.
- `storageKey: string` is now REQUIRED (no default). TypeScript
compile-fails any caller that omits it.
- Spec restated to make the per-page-key contract explicit.
3. Sensitive-field heuristic was too narrow. The previous regex
`AUTH_TOKEN|API_KEY|SECRET|PASSWORD|PRIVATE_KEY` missed common
secret names (ACCESS_TOKEN, REFRESH_TOKEN, BEARER_TOKEN,
CLIENT_SECRET, CLIENT_ID, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,
GCP/Azure/GitHub/OpenAI/Anthropic variants, JWT, OAUTH, CREDENTIAL,
PAT, WEBHOOK_SECRET, HMAC_KEY, SIGNING_KEY, SSH_KEY).
- New `src/lib/sensitive-label.ts` Single Source of Truth
(`isSensitiveLabel(label)`) with broadened regex; case-insensitive
and tolerant of `_`/`-` separators.
- `Field` imports the shared helper; future consumers do too.
- Spec §5g enumerates the new patterns and points at the SSoT.
Decisions log: v1.7 entry records the rationale and the connections
between spec wording and library API constraints, so the next reviewer
sees the trail rather than re-discovering it.
Validation: typecheck + lint + format clean; build clean; tests
519/521 pass (2 pre-existing account-visual-groups failures on dev,
unrelated). Styleguide demos already pass storageKey explicitly.
CCS - Claude Code Switch
The multi-provider profile and runtime manager for Claude Code and compatible CLIs
Run Claude, Codex, Droid-routed profiles, GLM, local models, and Anthropic-compatible APIs without config thrash.
Why CCS
CCS gives you one stable command surface while letting you switch between:
- multiple runtimes such as Claude Code, Factory Droid, and Codex CLI
- multiple Claude subscriptions and isolated account contexts
- OAuth providers like Codex, Copilot, Kiro, Claude, Qwen, Kimi, and more
- API and local-model profiles like GLM, Kimi, OpenRouter, Ollama, llama.cpp, Novita, and Alibaba Coding Plan
The goal is simple: stop rewriting config files, stop breaking active sessions, and move between providers in seconds.
Quick Start
npm install -g @kaitranntt/ccs
ccs config
Then launch whatever runtime fits the task:
ccs
ccs codex
ccs --target droid glm
ccs glm
ccs ollama
OpenAI-Compatible Routing
CCS can now bridge Claude Code into OpenAI-compatible providers through a local Anthropic-compatible proxy instead of requiring a native Anthropic upstream.
ccs api create --preset hf
ccs hf
Need to manage the proxy manually?
ccs proxy start hf
eval "$(ccs proxy activate)"
The proxy also supports request-time profile:model selectors, scenario-based
model routing through proxy.routing, and explicit activation helpers such as
ccs proxy activate --fish.
Guide: OpenAI-Compatible Provider Routing
Related Project: claude-code-router
claude-code-router is an excellent standalone tool for routing Claude Code requests to OpenAI-compatible providers. CCS's local proxy and SSE transformation work was directly informed by CCR's transformer architecture.
Use CCR when you want a standalone router without CCS profile management.
Use CCS when you want the routing flow integrated with CCS profiles, runtime
bridges, and the existing ccs command surface.
Need the full setup path instead of the short version?
| Need | Start here |
|---|---|
| Install and verify CCS | /getting-started/installation |
| First successful session | /getting-started/first-session |
| Visual walkthrough | /getting-started/product-tour |
| Provider selection | /providers/concepts/overview |
| Full command reference | /reference/cli-commands |
| Troubleshooting | /reference/troubleshooting |
See CCS In Action
Usage Analytics
Track usage, costs, and session patterns across profiles. Deep dive: Dashboard Analytics.
Live Auth And Health Monitoring
See auth state, account health, and provider readiness without dropping into raw config. Deep dive: Live Auth Monitor.
OAuth Provider Control Center
Manage OAuth-backed providers, quota visibility, and proxy-wide routing from one place. CCS now surfaces round-robin vs fill-first natively in both CLI and dashboard flows instead of hiding that choice inside raw upstream controls. The original CLIProxyAPI backend remains the default; the community-maintained CLIProxyAPIPlus fork is opt-in for plus-only providers. Deep dive: CLIProxy API.
Managed Tooling And Fallbacks
CCS can provision first-class local tools like WebSearch and image analysis for third-party launches instead of leaving you to wire them by hand. Browser automation now has a first-class setup path as well. Deep dive: WebSearch | Browser Automation.
Docs Matrix
The README stays short on purpose. The docs site owns the detailed guides and reference material.
| If you want to... | Read this |
|---|---|
| Understand what CCS is and how the pieces fit together | Introduction |
| Install CCS cleanly on a new machine | Installation |
| Go from install to a successful first run | Your First CCS Session |
| See the dashboard and workflow surfaces before setup | Product Tour |
| Compare OAuth providers, Claude accounts, and API profiles | Provider Overview |
| Learn the dashboard structure and feature pages | Dashboard Overview |
| Configure profiles, paths, and environment variables | Configuration |
| Understand browser attach vs Codex browser tooling | Browser Automation |
| Keep OpenCode aligned with your live CCS setup | OpenCode Sync Plugin |
| Browse every command and flag | CLI Commands |
| Recover from install, auth, or provider failures | Troubleshooting |
| Understand storage, config, and architecture details | Reference |
Example Workflow
# Design with default Claude
ccs "design the auth flow"
# Implement with a different provider
ccs codex "implement the user service"
# Use a cheaper API profile for routine work
ccs glm "clean up tests and docs"
# Run a local model when you need privacy or offline access
ccs ollama "summarize these logs"
Community Projects
| Project | Author | Description |
|---|---|---|
| opencode-ccs-sync | @JasonLandbridge | Auto-sync CCS providers into OpenCode |
Contribute And Report Safely
- Contributing guide: CONTRIBUTING.md
- Daily local gate:
bun run format && bun run lint:fix && bun run validate(validateis the fast path only) - Before review or merge confidence:
bun run validate:ci-parity - If PR checks stay queued for more than 10 minutes, assume the self-hosted runner is offline and notify a maintainer instead of retrying blindly
- Starter work: good first issue, help wanted
- Questions: open a question issue
- Security reports: SECURITY.md and the private advisory form