Manage isolated Claude Code configuration directories. Each env gets its own settings.json, plugins, hooks, and session history, independent of ~/.claude/. Think virtualenv for Claude Code.
See projects/cenv/2026-04-15-cenv-design.md in the pickleton repo for the full design.
go install github.com/technicalpickles/cenv/cmd/cenv@latest
cenv create auto-copies your OAuth login from ~/.claude into the new env, so new envs are already authenticated:
cenv create my-env # copies OAuth (keychain + oauthAccount) from ~/.claude
cenv run my-env -- -p 'hi' # env is authenticatedCloning from another cenv env works the same way:
cenv create my-clone --from my-env # my-clone is also authenticatedIf you want to authenticate fresh (different account, or source has no OAuth), cenv login <env> drops you into Claude's REPL for /login. cenv login requires a terminal.
For scripts and agents, cenv run fails fast with a message pointing at cenv login if the target env has never been authenticated.
Claude Code's sandbox blocks writes outside an allowlist. cenv stores envs at ~/.local/share/cenv/ (or $CENV_BASE), so fresh installs hit operation not permitted on first cenv create.
Add the env base to your sandbox allowWrite list in .claude/settings.json:
{
"sandbox": {
"filesystem": {
"allowWrite": [
"~/.local/share/cenv"
]
}
}
}If you set CENV_BASE, add that path instead.
Common tasks are defined in mise.toml. With mise installed:
mise install # install the Go toolchain pinned in mise.toml
mise run build # build ./cenv
mise run install # go install ./cmd/cenv
mise run test # go test ./...
mise run check # fmt + vet + testWithout mise, the raw commands work too:
go build -o cenv ./cmd/cenv
go install ./cmd/cenv
go test ./...cmd/cenv/— CLI entry point and subcommandsinternal/— supporting packagesdocs/plans/— design docsscratch/— throwaway exploration (gitignored where appropriate)