Bring an existing setup

You probably already have a folder or a repository of Claude Code and Codex tools you like: skills, agents, commands, rules, output styles, settings, hooks, and MCP servers. This page moves all of it into Code Config with csc. Your tools go into a GitHub repository Code Config reads, the way you group them becomes toolkits, and your keys and sign-ins stay on each computer. Keep the old folder working until the last section.

Before you start

Keep a backup of configuration you maintain yourself. Complete Get started, and check your coding-app guide for the files Code Config writes.

What moves, and where it lands

What you have	Where it goes	How
Skills, agents, commands, rules, and output styles	Your tools repository on GitHub (a private one works)	Files in the layout below, then `csc catalog index`
Settings and hooks	The same repository	The same
MCP servers	The same repository, as `.mcp.json` entries that name each key instead of holding it	The same
Key values (API keys, tokens, passwords)	Each computer, in the store Code Config manages	`csc key set`
Claude Code and Codex sign-ins, API-key providers	Each computer, as named accounts	`csc account add`
Which folder uses which setup	Your workspace, as each project’s toolkit	`csc project set`
Which tools go together	Your workspace, as toolkits	`csc toolkit create` and `csc toolkit set`

A key value stays on the computer that uses it: it is not in the repository and it is not sent to Code Config. A tool’s files stay in your repository, and Code Config reads them from GitHub when you index it.

Take stock

List what the old folder holds, in four groups:

Yours: skills, agents, commands, rules, output styles, settings, and hooks you wrote. These go in your repository.
Public tools you copied in: a skill or server someone else published. Don’t copy it again. Find it in the catalog with csc catalog search --query <name> and add it from there, so you get its updates.
Forks and vendored trees, such as a clone of someone else’s skills repository: skip the copy and add the published original from the catalog. If the catalog doesn’t have it, index it yourself with csc catalog index --repo <address>, giving its GitHub address.
Scripts, caches, histories, and other saved state: these stay out. They are not tools.

Whether you start a fresh repository or clean out an existing one is up to you.

Lay out the repository

skills/<name>/SKILL.md      one folder per skill; SKILL.md has a name and a description
agents/<name>.md            frontmatter: name, description
commands/<name>.md
rules/<name>.md
output-styles/<name>.md     frontmatter: name, description
settings/<name>.json        your Claude Code settings.json as it is
.claude/settings.json       the "hooks" block, with its scripts under .claude/hooks/
.claude/hooks/<script>
.mcp.json                   your MCP servers

Fix every path. A skill, agent, hook, or setting that points into the old folder has to point at a file inside the repository, or drop the reference. A hook names its script from the repository root, as .claude/hooks/<script>.

Each server in .mcp.json takes one of three forms:

A published package stays as npx <package> or uvx <package>.
A server you reach over the network is { "type": "http", "url": "https://…", "headers": { … } }. An MCP server you reach over the network may use an http:// address when it runs on your own network; sharing a toolkit to the community needs https://.
A program on your computer is the command that starts it. Every launch starts that program exactly as the file names it, by its name or by a path from the project folder, so install it on each computer you launch from:

{
  "mcpServers": {
    "my-company-mcp": { "command": "my-company-mcp", "args": ["--port", "0"] }
  }
}

Write every value in a server’s env and headers as ${NAME}, never as the value itself, including a value that is not a secret. Each ${NAME} becomes a named key slot on that server, and you give it a value on each computer in Set the keys. A server’s address is written out in full.

Settings: settings/<name>.json is your Claude Code settings.json as it is. Fix anything in it that names a path outside the repository, such as a status line command. Hooks go in .claude/settings.json, with their scripts in .claude/hooks/, not in the settings file.

Commit and push.

A skill, agent, or command you keep only on this computer comes in another way. Set your private tools repository under Settings in the web app, then write or change the tool in a coding-app session Code Config launched. Code Config saves it to that repository and adds it to the session’s toolkit. Private tools repository explains when a save happens and where each tool lands. Do not upload ordinary project files as a substitute for bringing tools over.

Index the repository

csc catalog index --repo https://github.com/<owner>/<repository> --json
csc catalog get --repo https://github.com/<owner>/<repository> --json

The first command reads the repository’s newest commit. After that, Code Config reads each push to the repository’s default branch on its own, and running the command again answers with an empty changed list and the tools it already holds. The second lists every tool by kind, each with its id and whether it can go in a toolkit (addable). Keep the ids for the next step.

A private repository needs the code-config.com GitHub App to have access to it; see Private repositories.

Make the toolkits

A toolkit is for a kind of work, not for a person or a folder. Make one base toolkit for what every launch should have, such as your team’s rules, settings, hooks, output styles, and shared servers, and one toolkit for each kind of work. Understand toolkits explains why smaller toolkits work better.

csc toolkit create --name "Base" --add-tools <tool-id> --add-tools <tool-id> --json
csc toolkit create --name "Frontend" --add-tools <tool-id> --json
csc toolkit create --name "Shop site" --default --json
csc toolkit set --toolkit "Shop site" --include "Base" --include "Frontend" --json

--add-tools takes the ids from the last step, repeated or comma-separated. --default makes the toolkit the one a launch uses when nothing else chooses. --include adds a toolkit to the end of the included list, and --remove-include takes one out. A launch takes the included toolkits in order, then the toolkit itself; where two of them carry the same server, the later one’s server and its keys win.

An included toolkit can include toolkits of its own, up to 8 toolkits deep. A launch takes each included toolkit’s own includes before it, so a “Frontend” toolkit that includes “Base” brings Base along wherever it goes. A toolkit can’t include a toolkit that already includes it; Code Config says which two toolkits that would loop.

Pick or pin a toolkit that includes the base. A piece, a toolkit that others include such as one server with its key, has no base on its own.

Two toolkits can share a name. A command given a name that two toolkits share is refused and lists each of them, so give the id whenever you have it; csc toolkit get --json lists every toolkit with its id.

A project that needs its own key for a server the others share gets its own toolkit, which carries that server and includes the base. The key set on that toolkit’s server is the one its launches use. Choose which key a tool uses covers keeping two slots on two different keys.

Set the keys

csc key get --toolkit "Base" --json
printf '%s' '{"API_TOKEN": {"file": "/path/to/old/folder/.env", "name": "API_TOKEN"}}' \
  | csc key set --toolkit "Base" --server <server> --json

csc key get lists every key slot the toolkit’s servers and apps need, whether this computer has it, and the command that sets it. csc key set reads one JSON object on standard input, keyed by setting name. Give each entry as where the value already is: { "file": "path", "name": "NAME" } for one variable of a .env file, { "file": "path" } for a whole file, { "env": "NAME" } for a variable of your shell, or { "command": "COMMAND" } for what a command prints. The value then moves from the old file into the store without appearing on a command line or in your shell history. Credential storage and permissions covers the store.

A key your whole company uses: each person runs the same csc key set on their own computer, with the value they were given. There is no central copy, by design.
A key that is only yours: the same command, with your own value.
A project that needs a different key for the same server: its own toolkit carries the server (see Make the toolkits); set the key there.

Then let Code Config finish what this computer can do on its own:

csc setup run --toolkit "Shop site" --no-open --wait --json

Its answer says done, or names what is left, such as a sign-in.

Pin folders

csc project set --path ~/code/shop --toolkit "Shop site" --json
csc project get --path ~/code/shop --json

Run csc project set once for each folder that should use a toolkit other than your default. A folder that isn’t a project yet becomes one in the same command. The toolkit is pinned to the project in your workspace, and the folder is connected to that project on this computer, so run the same command for the folder on each computer you work from. csc project get reads each pin back, and the web app’s Projects page lists them. Connect a project and choose defaults covers the other ways to connect a folder.

Add the accounts

A coding-app account is separate from your code-config.com sign-in. Add one account for each sign-in you keep:

csc account add work --host claude --import-current
csc account add personal --host claude --import-from ~/.claude-personal
csc account add work-codex --host codex --import-from ~/.codex-work
<command that prints the key> | csc account add kimi --host claude --api --preset kimi --key-stdin

--import-current copies the sign-in Claude Code uses now. --import-from copies one kept in another folder, and --host codex makes it a Codex sign-in. --api --preset makes an account for a provider you pay by API key, reading the key on standard input. Each copies a sign-in into a Code Config account folder; it does not import tools or settings. Coding-app accounts and models covers the other options.

Check the new setup before you switch

In a pinned folder, launch with the toolkit:

cd ~/code/shop
csc launch --host claude --toolkit "Shop site" --account work --strict --json

csc launch prepares the session and starts the app, saying as it goes which toolkit, tools, account, and servers it put in place. --strict makes the command exit with code 5 when anything the toolkit asked for is not in place, and names each one. In the session, check that the skills are there, that each server answers, and that the keys you set are in use.

On a computer with no display, run csc launch at a terminal prompt and the coding app takes over that terminal. A launch with no terminal of its own, such as one a script or an agent starts, runs the coding app in a tmux session when that computer has tmux; without it, the launch stops and says to run csc launch in a terminal there.

Launch every toolkit you pin or pick, not only the pieces: a toolkit made of other toolkits is where the setup proves itself. Two things such a launch reports are by design:

A server that two of its toolkits carry under one name is written once, from the later toolkit.
An agent written in Codex form is not placed on Claude Code. The launch names it under item_not_placed.

Check that the model and permissions are appropriate, and read any conversion notes. Leave your previous setup available until the new launch works for your actual task.

For Codex, toolkit settings are applied to a launch copy. User choices such as approvals can be carried back when the run ends; see Codex.

Retire the old folder

Stop the shell wrappers that set CLAUDE_CONFIG_DIR to the old folder.
Remove any job that copied or synced the old folder to your computers.
Keep the old folder read-only until you have launched every toolkit once, then archive it.

Create and manage toolkits covers changing a toolkit later, and the command-line reference lists every command and its options.