Fixed:
- Migration now runs during installation across all methods (npm, bash, PowerShell)
- Guarantees ~/.ccs/shared/ populated immediately with ~/.claude/ content
- Users no longer need to run ccs command to trigger migration
Changed:
- Refactored SharedManager with _needsMigration() and _performMigration() methods
- _copyDirectory() returns {copied, skipped} stats and preserves existing files
- Shows detailed migration output: '[OK] Migrated 5 commands, 19 skills'
- Removed lazy migration from bin/ccs.js, lib/ccs, lib/ccs.ps1
Implementation:
- npm: Migration in scripts/postinstall.js
- bash: Migration in installers/install.sh (migrate_shared_data function)
- PowerShell: Migration in installers/install.ps1 (Invoke-SharedDataMigration)
- Fixed arithmetic expansion with set -e (changed ((var++)) to var=$((var + 1)))
Cross-platform parity maintained across all installation methods.
Phase 1: Multi-profile shared data via symlinks
Added:
- SharedManager class for symlink orchestration (bin/shared-manager.js)
- Auto-migration from ~/.claude/ to ~/.ccs/shared/ on first run
- Shared directories: commands/, skills/, agents/
- Windows fallback: copies dirs if symlinks fail
Fixed:
- Migration logic now detects empty directories
- Previously skipped migration when postinstall created empty dirs
- Now properly copies from ~/.claude/ when shared dirs are empty
Changed:
- Instance initialization symlinks to shared dirs instead of copying
- Postinstall creates ~/.ccs/shared/ structure automatically
- All implementations (Node.js, bash, PowerShell) updated for consistency
- Help text includes agents/ in shared data section
Technical:
- Profile-specific data remains isolated (settings, sessions, todolists, logs)
- Migration is idempotent: safe to run multiple times
- Cross-platform symlink support with graceful fallback
Closes#4
This release fixes default profile behavior and streamlines help output.
Breaking Changes:
- Profile creation NO LONGER auto-sets as default
- Users must explicitly run `ccs auth default <profile>` to set default
- Without explicit default, `ccs` uses implicit default from ~/.claude/
Auth Default Behavior:
- Removed auto-set default logic in profile-registry.js
- Removed auto-set default in bash register_profile() function
- Removed auto-set default in PowerShell Register-Profile function
- Implicit 'default' profile always exists (uses ~/.claude/)
- Enhanced success messages guide users to set explicit default
- Updated auth help with examples and note about default behavior
Help Text Simplification:
- Removed lengthy Examples section from main help (~40% shorter)
- Condensed Account Management section to `ccs auth --help`
- Kept detailed examples in `ccs auth --help` where relevant
- Consistent across npm, bash, and PowerShell implementations
Files Changed:
- bin/profile-registry.js: Removed auto-default logic
- bin/auth-commands.js: Updated help and success messages
- bin/ccs.js: Simplified main help text
- lib/ccs: Fixed bash implementation + simplified help
- lib/ccs.ps1: Fixed PowerShell implementation + simplified help
- VERSION, package.json, installers/*: Version bump to 3.0.2
Fixes #TBD
- Add auto-recovery mechanisms for missing/corrupted configuration files
- Implement comprehensive health check command (`ccs doctor`)
- Enhance error messages with context-aware diagnostics and recovery commands
- Fix silent postinstall failures - now exits with proper error codes
- Add RecoveryManager class for automatic config restoration
- Add ErrorManager class for structured, helpful error messages
- Update postinstall script to validate created files and auto-create ~/.claude/settings.json
- Add doctor command support to bash and npm implementations
- Implement atomic file operations to prevent corruption
- Add comprehensive testing scenarios and validation
Fixes critical issue where npm install succeeded but CCS failed on first run.
Enhances user experience with automatic recovery and clear error guidance.
BREAKING CHANGE: Postinstall now exits with error code 1 on critical failures
* feat: implement native multi-account switching with isolated instances
Add account-based profile management system that enables users to run
multiple Claude accounts concurrently with complete isolation.
Key features:
- Profile registry (~/.ccs/profiles.json) tracks account profiles
- Instance isolation (~/.ccs/instances/<profile>/) for each account
- Auth commands: create, list, show, remove, default
- Backward compatible with settings-based profiles (GLM, Kimi)
- Auto-copies global .claude configs to new instances
Implementation:
- Phase 1: Profile detection logic (account vs settings-based)
- Phase 2: Instance management (initialization, validation)
- Phase 3: Auth CLI commands
- Phase 4: Profile registry CRUD operations
- Phase 5: Execution routing based on profile type
Both lib/ccs (bash) and lib/ccs.ps1 (PowerShell) updated for
cross-platform support.
* fix(ci): add pull_request trigger to satisfy branch protection
The branch protection rule requires "Deploy ccs-installer to CloudFlare"
status check to pass, but the workflow only ran on push to main branch.
This caused PRs to wait indefinitely for a status that never reported.
Changes:
- Add pull_request trigger with same path filters
- Split deployment into conditional steps:
- PR mode: dry-run validation only (--dry-run flag)
- Production: actual deployment (push to main only)
- Keeps same job name to satisfy branch protection requirement
Security:
- No deployment from PR branches (dry-run only)
- Production deploy only when push to main AND ref check
- Secrets used safely in both contexts
This fixes PR #3 which was stuck waiting for status.
* fix(ci): remove path filter from pull_request trigger
The path filter prevented workflow from running on PRs that don't
modify worker/installer files, causing required status check to
never report. This blocked PR #3 indefinitely.
Changes:
- Remove paths filter from pull_request trigger
- Keep paths filter on push to main (optimize deployments)
- Workflow now runs on ALL PRs to satisfy branch protection
Trade-off:
- PRs changing non-worker files will trigger unnecessary dry-run
- But this ensures required status check always reports
- Small cost for reliability and simpler configuration
Alternatives considered:
- Path-aware required checks: Not supported by GitHub
- Remove required check: Loses CI validation
- Add all paths to filter: Makes config brittle
- Add ANTHROPIC_SMALL_FAST_MODEL to all Kimi configuration templates
- Update installation scripts (npm, Unix, Windows) to include SMALL_FAST_MODEL
- Ensure Kimi API configuration matches official documentation format
- Bump version to 2.5.1 with updated changelog
Files updated:
- config/base-kimi.settings.json: Add SMALL_FAST_MODEL
- installers/install.sh: Update Unix template creation
- installers/install.ps1: Update PowerShell template creation
- scripts/postinstall.js: Update npm postinstall script
- All version files: Bump to 2.5.1
- Add kimi profile support alongside existing glm and default profiles
- Create base-kimi.settings.json configuration template
- Update all installation methods (npm, Unix, Windows) to auto-create Kimi settings
- Enhance documentation with Kimi examples and API setup instructions
- Update version to 2.5.0 with comprehensive changelog
- Add Kimi detection logic in install scripts for seamless migration
- Maintain backward compatibility with existing GLM and Claude profiles
Use string concatenation (not args array) when shell is needed to avoid
Node.js DEP0190 deprecation warning. Restores previous working approach
with conditional shell usage based on file extension.
Key changes:
- Added escapeShellArg() helper for proper argument escaping
- Conditional shell: only for .cmd/.bat/.ps1 files on Windows
- When shell needed: concatenate args into single escaped string
- When no shell: use array form (faster, no overhead)
Benefits:
- No deprecation warning
- Proper security (escaped arguments)
- Better performance (no shell on Unix or for .exe files)
- Matches previous stable implementation
Version: 2.4.9
Use platform-specific shell option (Windows only) instead of shell: true
to avoid deprecation warning in Node.js v22.9.0+.
Changes:
- bin/ccs.js: Change shell: true to shell: process.platform === 'win32'
- CHANGELOG.md: Document fix for v2.4.8
- VERSION: Bump to 2.4.8
- package.json: Bump to 2.4.8
Benefits:
- No deprecation warning on Windows
- Better performance on Unix (no shell overhead)
- Maintains Windows .cmd/.bat compatibility
- fix color detection for cross-platform TTY compatibility
- enhance help command with npm-specific content and npx examples
- remove --install/--uninstall flags pending .claude/ integration testing
- update version across all files and documentation
- preserve implementation code for future release readiness
kaitranntt