Skip to main content

File Locations

Reference for CCS configuration, credentials, cache, logs, and runtime paths. Base Directory: ~/.ccs/ (override with CCS_DIR, or legacy CCS_HOME which appends .ccs)

Overview

Path precedence is --config-dirCCS_DIR → legacy CCS_HOME/.ccs → default ~/.ccs/.

Configuration Files

~/.ccs/config.yaml

Purpose: Main unified configuration file (v13) Format: YAML Created: First run, or via ccs setup Delete: Only if resetting CCS completely Contains:
  • Default profile setting
  • Account-based profiles
  • API-based profiles
  • CLIProxy configuration
  • User preferences
  • WebSearch settings
  • Global environment variables
  • Quota management (v7+)
  • Thinking configuration (v8+)
  • Dashboard authentication
  • Image analysis configuration (v8+)
  • Deprecated Copilot compatibility settings
  • Remote/local proxy configuration
  • OpenAI-compatible local proxy configuration (v13+)
  • Browser automation configuration (v13+)
Example:
Related:

~/.ccs/*.settings.json

Purpose: Profile-specific environment variables Format: JSON Created: Via ccs api create <name> or dashboard Delete: Safe to delete (profile becomes unusable) Naming Pattern: ~/.ccs/<profile-name>.settings.json Contains:
Security: Store securely, do not commit to version control Examples:
  • ~/.ccs/glm.settings.json - GLM profile
  • ~/.ccs/km.settings.json - Kimi for Coding profile
  • ~/.ccs/xai.settings.json - xAI (Grok) provider settings
  • ~/.ccs/custom-api.settings.json - Custom API profile
grok is an xAI CLI alias; it does not create grok.settings.json.

CLIProxy Files

~/.ccs/cliproxy/auth/xai-*.json

Purpose: xAI OAuth credentials Created: ccs xai --auth or ccs grok --auth The token JSON uses "type": "xai". Email metadata can be absent, so CCS uses an email when present or derives the account ID from the token filename suffix. The account registry stores xAI metadata at providers.xai in accounts.json; grok does not create separate token files or a registry bucket.

~/.ccs/cliproxy/sessions.json

Purpose: Global session tracking for CLIProxy Format: JSON Created: First CLIProxy session Delete: Safe (sessions will reset) Structure:
Use Cases:
  • Track concurrent sessions per provider
  • Prevent proxy shutdown with active sessions
  • Debug session leaks
Related: ~/.ccs/cliproxy/sessions-{port}.json for port-isolated variants

~/.ccs/cliproxy/sessions-{port}.json

Purpose: Port-specific session tracking for variants Format: JSON Created: First session on variant with custom port Delete: Safe (variant sessions will reset) Naming Pattern: ~/.ccs/cliproxy/sessions-8318.json Structure:
When Created:
  • Variant has port specified in config.yaml
  • Port range: 8318-8417
Related:

~/.ccs/cliproxy/accounts.json

Purpose: OAuth account registry for CLIProxy providers Format: JSON Created: First OAuth authentication Delete: Removes all OAuth accounts (requires re-auth) Structure:
Operations:
  • Add account: ccs codex --auth --add
  • List accounts: ccs codex --accounts
  • Switch account: ccs codex --use <nickname>
  • Rename account: ccs codex --nickname <new-name>
Related:

~/.ccs/cliproxy/config-{port}.yaml

Purpose: Port-specific CLIProxy configuration Format: YAML Created: Automatically for variants with custom ports Delete: Safe (will regenerate on next use) Naming Pattern: ~/.ccs/cliproxy/config-8318.yaml Contains:
  • Provider-specific settings
  • Port configuration
  • Auth credentials (if variant-specific)
  • Logging settings
When Created:
  • Variant has port: 8318 in config.yaml
  • Allows concurrent variants without config conflicts
Related:

~/.ccs/cliproxy/bin/original/

Purpose: CLIProxyAPI (original) binary directory Format: Directory containing executable + version file Created: During CLIProxy installation (backend: original) Delete: Safe (will reinstall on next use) Files:
  • cli-proxy-api — CLIProxyAPI binary
  • version.txt — Installed version string
Use Cases:
  • Standard providers: gemini, codex, xai, agy, iflow, kimi, claude
  • Minimal install without the plus-only provider set

~/.ccs/cliproxy/bin/plus/

Purpose: CLIProxyAPIPlus binary directory Format: Directory containing executable + version file Created: During CLIProxy installation (backend: plus) Delete: Safe (will reinstall on next use) Files:
  • cli-proxy-api-plus — CLIProxyAPIPlus binary
  • version.txt — Installed version string
Use Cases:
  • Plus-only providers including Kiro, Cursor, GitLab Duo, CodeBuddy, Kilo AI, Qoder, and deprecated GitHub Copilot compatibility
  • Opt-in backend; original remains the default local backend
  • Legacy deleted-upstream Plus installs migrate safely to the original backend
Related Commands:
  • ccs cliproxy - Show current version
  • ccs cliproxy --install <version> - Install specific version
  • ccs cliproxy --latest - Update to latest

~/.ccs/model-catalog-cache.json

Purpose: Cached model catalog snapshot from CLIProxy management sync Format: JSON Created: Via ccs cliproxy catalog refresh Delete: Safe (reverts to static catalog; regenerates on next refresh) TTL: 24 hours Contains:
  • Model IDs and metadata per provider
  • Remote-overridden fields merged with static fallback
  • Last-synced timestamp
Related Commands:
  • ccs cliproxy catalog - View cache status
  • ccs cliproxy catalog refresh - Force refresh
  • ccs cliproxy catalog reset - Clear cache (revert to static)

~/.ccs/browser/chrome-user-data/

Purpose: Recommended dedicated Chrome user-data directory for Claude Browser Attach Format: Browser profile directory Created: Via ccs browser setup or first managed setup path Delete: Safe if you want to reset browser automation state Use Cases:
  • Keeps automation browser state separate from your daily browser profile
  • Works with Chrome launched via --remote-debugging-port=9222

~/.ccs/mcp/ccs-browser-server.cjs

Purpose: Managed local MCP runtime for Claude Browser Attach Format: JavaScript runtime file Created: When CCS prepares browser automation tooling Delete: Safe; CCS recreates it when browser tooling is prepared again Related Commands:
  • ccs browser setup
  • ccs browser status
  • ccs browser doctor

Claude Channel Token Files

~/.claude/channels/telegram/.env

Purpose: Telegram bot token for Official Channels integration Format: .env file with TELEGRAM_BOT_TOKEN=<token> Created: Via ccs config channels --set-token telegram=<token> Delete: Disables Telegram channel auto-enable Content:
Related:

~/.claude/channels/discord/.env

Purpose: Discord bot token for Official Channels integration Format: .env file with DISCORD_BOT_TOKEN=<token> Created: Via ccs config channels --set-token discord=<token> Delete: Disables Discord channel auto-enable Content:
Related:

Cache Files

~/.ccs/cache/usage.json

Purpose: Usage analytics cache (in-memory format) Format: JSON Created: First Claude Code session Delete: Safe (analytics will reset) Structure:
Use Cases:
  • Track daily/monthly usage
  • Model distribution analysis
  • Cost estimation
Related:
  • Dashboard Analytics page
  • /api/usage/* endpoints

~/.ccs/.cache/usage-cache.json

Purpose: Persistent usage cache (disk format) Format: JSON Created: On shutdown/periodic sync Delete: Safe (will rebuild from sessions) Difference from cache/usage.json:
  • cache/usage.json - In-memory, fast access
  • .cache/usage-cache.json - Persistent, survives restarts
Structure: Same as cache/usage.json Sync Behavior:
  • Write on graceful shutdown
  • Periodic sync every 5 minutes (if dirty)
  • Load on startup

~/.ccs/cache/update-check.json

Purpose: Update notification cache Format: JSON Created: First update check Delete: Safe (will re-check immediately) Structure:
Cache Duration: 24 hours Related:
  • ccs update - Manual update
  • Startup update notifications

Logs

~/.ccs/logs/

Purpose: CCS-owned structured runtime logs Format: JSONL Created: As CCS runtime events are written Delete: Safe (though you lose local history) Primary files:
  • current.jsonl - active structured log stream
  • archive/ - rotated segments pruned by logging.retain_days
Controlled by:
Structured logs may still contain sensitive operational context. Keep redaction enabled unless you are debugging locally and understand the tradeoff.

~/.ccs/cliproxy/logs/

Purpose: CLIProxy runtime log files Format: Plain text Created: When cliproxy.logging.enabled: true Delete: Safe (via ccs cleanup) Configuration:
CLIProxy logs can consume significant disk space. Enable only for debugging.
Log Types:
  • error.log - Error messages only
  • request.log - HTTP request/response (if request_log: true)
  • debug.log - Verbose debug output
Related:

Legacy Files (Pre-v8)

~/.ccs/config.json (deprecated)

Status: Deprecated in v8 Migration: Automatically migrated to config.yaml Delete: After successful migration Related:

~/.ccs/profiles.json (deprecated)

Status: Deprecated in v8 Migration: Merged into config.yaml under accounts section Delete: After successful migration

Backup Files

~/.ccs/backup-v1-YYYY-MM-DD/

Purpose: Migration backups Created: During config migration (v1 → v8) Delete: Safe after verifying migration success Contains:
  • config.json - Legacy config
  • profiles.json - Legacy profiles
  • usage-cache.json - Pre-v8 cache
Recovery:
List Backups:

Shared Data

~/.ccs/shared/

Shared profiles use ~/.ccs/shared/ as the managed access layer for resources whose canonical source is under ~/.claude/:
On macOS and Linux these entries are symlinks. Windows can fall back to copies when symlinks are unavailable. ccs sync repairs the shared access layer. CLAUDE.md is shared by default for non-bare account profiles. CCS creates an empty canonical file when no copy exists. If the canonical file is missing, one unique existing variant is adopted; multiple distinct variants are kept as CLAUDE.md.ccs-shared-conflict[-N] files for explicit recovery. When the canonical file exists, it always wins and any divergent copy is also preserved with that suffix.

Instance Directories (Account Profiles)

~/.ccs/instances/<name>/

Account profiles use independent CLAUDE_CONFIG_DIR roots. Credentials, sessions, and history remain profile-specific, while non-bare profiles link managed shared resources at the instance root:
Profiles created with --bare, or switched to profile-local, do not use the managed shared links. See Claude Accounts.

Temporary Files

~/.ccs/tmp/

Purpose: Temporary files during operations Format: Various Created: During migrations, updates, etc. Delete: Safe (auto-cleaned) Auto-Cleanup:
  • On successful operation completion
  • Via ccs cleanup
  • On startup (files older than 24h)

Quick Reference Table


Cleanup Strategy

1

Regular Cleanup

Run monthly or when disk space is low.
2

Deep Cleanup

Run if troubleshooting or resetting environment.
3

Complete Reset

Only if reinstalling CCS completely.