Import your setup

You don't have to start from scratch. Cusp reads the common instruction and configuration formats where they already are, and the import converts the rest into Cusp's own files. Your instructions, skills, subagents, hooks and MCP servers work as they are.

This page lists what Cusp reads in place, what the import converts for each source, how Cusp's files and the shared ones coexist, and what doesn't carry over yet.

Read in placeCopy Anchor Link

These files need no import. Open a project that has them and they're active:

What the import convertsCopy Anchor Link

Some agents keep their configuration in formats Cusp doesn't read directly. The import converts them into .cusp/ files. It copies; it never moves or deletes the originals.

Secrets never come over. API keys and tokens in MCP or settings files become ${VAR} references, and the import lists the variables to set at the end. Settings that skip approvals or redirect traffic stay off unless you choose them.

In the desktop appCopy Anchor Link

When you first set up Cusp, the Bring your setup step lists the agents it found on your computer. Review what comes over shows every item with a checkbox and the exact file changes before anything is written.

From the CLICopy Anchor Link

cusp import codex --dry-run    # show the diffs, write nothing
cusp import cursor             # import this project's Cursor setup
cusp import gemini --user      # user-level configuration instead of the project

The source is one of claude-code, codex, gemini or cursor. --all imports both project and user level. --force replaces existing .cusp/ files that differ; by default they're kept.

How .cusp/ and shared files coexistCopy Anchor Link

Every place Cusp reads a shared .claude/ path, it also reads the matching .cusp/ path. At the same level, .cusp/ wins:

So you can keep sharing these files with teammates who use other agents, and put Cusp-only tweaks in .cusp/.

Tool and rule namesCopy Anchor Link

Cusp's tools use the names and input fields that existing hooks, permission rules and skills are written against: Read, Write, Edit, MultiEdit, Bash, Grep, Glob, WebFetch, Agent, Skill, with file_path, old_string, new_string, command, and so on.

Some models see a different name on the wire. GPT-family models edit with apply_patch and plan with update_plan, because that is what they were trained on. Hooks and permission rules always see the canonical name, so an Edit(src/**) rule also covers ApplyPatch and EditLines. See Tools.

Permission modesCopy Anchor Link

Project and local settings can't set auto or bypassPermissions as the default mode. Only your user settings can. See Permissions.

HooksCopy Anchor Link

Cusp supports five handler types (command, http, mcp_tool, prompt, agent) and the full event list, including PreToolUse, PostToolUse, UserPromptSubmit, Stop, SessionStart and PreCompact. Exit code 2 blocks, JSON on stdout decides, and both ${CLAUDE_PROJECT_DIR} and CUSP_PROJECT_DIR are set, along with CUSP_HOOK_EVENT. See Hooks.

A hook script that checks tool_name == "Edit" will also see GPT models' edits as Edit-family calls named ApplyPatch. If your script filters on the exact tool name, add ApplyPatch, MultiEdit and EditLines to the list, or match on tool_input.file_path.

What doesn't carry over yetCopy Anchor Link

• Auto memory written by other agents isn't read. Cusp keeps its own auto memory.
• In-process UI extensions that patch another agent's own interface have no equivalent in Cusp.
• Keybindings files from other agents. Cusp's shortcuts are listed in Keyboard shortcuts.
• Gemini CLI extensions are listed by the import, not installed. Plugins in the .claude-plugin format install with cusp plugin; see Hub.

Checking what loadedCopy Anchor Link

Run /status in the CLI to see the daemon, session, model and workspace. Settings files that fail to parse are reported with the file path and the reason; an invalid key is dropped with a warning instead of discarding the whole file.