Slash Commands

Command Code ships with over 60 built-in slash commands covering sessions, context, permission modes, models, billing, and everything in between - and you can extend the set with your own custom commands, skills, and mod-added commands.

How the slash menu works

Type / at the start of the input to open the command menu:

• Filtering - as you type, rows are ranked by match quality: a command whose name starts with your query ranks highest, then commands containing it, then description matches. The list re-sorts on every keystroke.
• Exact-match highlighting - the input text stays plain while you type a partial name; it only turns accent-colored once it names a real command (a half-typed /mod stays plain, /model lights up).
• Aliases on canonical rows - an alias is not a second menu row. /new resolves to /clear everywhere, and the single canonical row advertises it as /clear (new). Typing the alias still surfaces and ranks that row.
• Navigation - ↑/↓ move the selection, Enter runs the selected command, Tab or → inserts it into the input with a trailing space so you can type arguments, Esc closes the menu.
• Dynamic rows - custom commands, mod commands, and skills load asynchronously; built-ins render first and the dynamic rows appear as discovery settles.

Built-in commands

Every built-in command, grouped by area. Aliases are shown in parentheses on the canonical command; optional arguments in [brackets], alternatives separated by |.

Sessions

Context & compaction

Modes & planning

Models & providers

Extensibility & integrations

Workspace

Billing & account

Utilities

Command behavior

Bare invocations that open a picker

/model, /effort, and /theme each take an optional value (/model gpt-5, /effort high, /theme dark) that applies directly as a one-shot. But unlike other optional-value commands, running them bare doesn't perform a default action - it opens an interactive picker immediately. Bare /mode also runs immediately, printing the current mode and the available switches (/mode:default, /mode:accept-edits, /mode:plan - or press shift+tab to cycle).

/effort only opens its selector when the current model supports reasoning effort levels; otherwise it prints a notice that effort isn't supported for that model.

/theme offers three values. dark and light pin a palette; auto, the default, automatically detects your terminal's background color at startup (OSC 11, falling back to COLORFGBG) and uses light or dark to match. A terminal that won't report its background falls back to dark.

Commands with meaningful default actions when bare

Some optional-argument commands do something useful with no argument instead of opening a picker: bare /import imports from all detected sources, bare /export exports in the default format, bare /goal (or /goal status) shows the current goal, bare /name shows the current session name, and bare /plan enters plan mode without a task.

Safe while the agent is busy

Most commands are blocked mid-turn - mode flips, session switches, model changes, compaction, and anything that would race an active turn waits until the agent finishes. A deliberate set of read-only or local commands stays available while a turn is running:

• /trace - capture the live trace id of the running turn (its main purpose)
• /session-file - read-only session facts
• /copy - clipboard only
• /todos (also ctrl+x) - edits local todo state, most useful mid-turn while a plan is being driven (needs the todos mod enabled)
• /statusline off, /statusline on, /statusline reset - a local display preference (bare /statusline opens its editor once the turn ends)
• /exit / /quit - always available
• /goal clear - stops the goal loop; the current step finishes, then the loop stops. Setting a new goal mid-turn is refused with a busy notice.

Most other commands - /clear, /mode, /plan, /model, /compact, /worktree, /resume, /login, and the like - report busy and ask you to wait for the current turn (or press Ctrl+C). (/review is an exception: it runs mid-turn.)

/goal in detail

/goal <objective> sets an objective (up to a length limit) and arms an autonomous loop capped at a maximum number of turns. /goal status (or bare /goal) shows the active goal and progress; /goal clear clears it. /goal resume and /goal pause are reserved but not available yet.

/loop in detail

/loop <interval> <task> runs the task now and repeats it on a fixed cadence such as 5m, 2h, 1d, or a trailing every 2 hours. /loop <task> runs it now and lets the agent pick each next delay, between one minute and one hour. Bare /loop runs the default maintenance task, which a .commandcode/loop.md file replaces. Esc cancels the conversation's loops. The /loop page has the normalization rules, loop.md, and resume behavior.

/statusline in detail

The status line is the row directly under the input. It stays visible while you type and steps aside only for the slash menu, the @ file list, the slash hint, and a pending Ctrl+C exit:

Bare /statusline slash command opens the statusline editor. Select items from the list to add to the statusline. An item with nothing to show right now says why in brackets beside its label, for example Git branch (not on a git branch), instead of showing a placeholder.

These items sit in the row, in the order you choose. Items marked off are unchecked by default:

These items keep their own place under the input; you can only turn them on or off. All are on by default:

The Ctrl+C exit prompt, credit warnings, and update, share and taste notices always show.

Unchecked items keep their place, so checking one again puts it back where it was. Nothing changes under the input until Esc saves the layout. If the write fails, the editor stays open with your changes, and Esc tries again; if another session changed the layout while you were editing, it never overwrites it: Enter reloads the saved version, Esc discards your changes. Closing the editor gives you back the prompt you were writing.

Output from mods (cmd.ui.setStatus) always appears after the built-ins, and before the phase model at the right end, in the order the mods loaded. Unchecking every built-in still shows mod output; /statusline off is the way to hide the whole row.

Add your own items with mods

The editor lists only the built-in items. To show anything else in the row, such as a CI result, a ticket number or a count, use a mod that calls cmd.ui.setStatus(text). Each mod gets one segment: a new call replaces its text, and null removes it. You don't need to write the mod yourself; describe what you want and Command Code builds it:

Command Code writes something like this and saves it in ~/.commandcode/mods/changed-files.ts, where it loads in every session:

The next session shows it in the row:

To try a mod without installing it, run cmd --mod ./changed-files.ts; after editing an installed one, run /reload. Mod text can use ANSI colors and OSC 8 links; other escape codes are removed. To hide mod output but keep the built-ins, set legacy-mods to "enabled": false in config.json (see below). The UI surface section of the mods page has the full setStatus contract.

Your items always get exactly one line under the input, in the order you set. When they don't fit your terminal, the line is cut with … at the edge rather than wrapping or reordering. The phase model sits at the right end of that line when it fits beside it, otherwise at the right end of the line below.

The layout is saved in ~/.commandcode/config.json under statusline. You rarely need to edit it by hand:

items sets the order, except that phase-model always draws at the right end. enabled: false on an item unchecks it; enabled: false at the top level is /statusline off. An item missing from items is unchecked, except the on/off-only items (permission-mode, ide, pull-request, taste, background-tasks, hints), which stay on. Other ids: model-reasoning, reasoning, cwd, session-name, version. legacy-mods is where mod output goes; leave it out (or set "items": []) and mod output is hidden.

A layout saved by a newer version of Command Code is never overwritten: the row uses the default layout and the editor opens read-only, until you update or run /statusline reset. A statusline value that isn't valid is also left untouched and shown read-only; fix or remove the statusline key, or run /statusline reset. If config.json itself isn't valid JSON, nothing can save the layout, /statusline reset included, until you fix or remove that file.

The row doesn't watch the file. A hand edit, or a save from another Command Code window, shows up the next time you open /statusline, run /statusline off, on or reset, or restart.

/rc in detail

Bare /rc opens the picker: platform, setup, permission mode. /rc default, /rc auto-accept and /rc yolo connect straight into a mode. /rc status reports what is on, /rc off disconnects, and /rc off clear also deletes the bot's own messages. /rc is refused when the model asks for it and when it arrives from the chat, so the bot cannot change its own token or allowlist. See /rc for setup and what the chat can send.

Custom slash commands

Custom slash commands let you save frequently used prompts as markdown files. Define a command once, then run it anytime with dynamic arguments.

The command name comes from the markdown filename (without the .md extension).

Locations

The file's full trimmed body is the prompt that runs; the slash menu shows its first meaningful line (skipping YAML frontmatter and markdown markers, truncated to ~80 chars) plus the location label.

Namespacing

Organize commands in subdirectories to any depth. The subdirectory appears in the description label but does not affect the command name:

Argument templating

Placeholders in the command body are replaced with your arguments in a single pass (substituted text is never re-scanned, so an argument containing $1 lands literally):

Arguments split on whitespace, respecting single and double quotes:

Example (.commandcode/commands/commit.md):

Edge cases: an out-of-range slice (${@:9} with three args) expands to an empty string; an unrecognized ${...} expression (e.g. a literal ${HOME}) is left untouched so shell/env-style text survives; a template with no placeholders passes through unchanged.

Dispatch precedence

When multiple sources define the same name, dispatch resolves in this order - first writer wins:

1. Built-in commands (the full set, including any the menu hides)
2. Mod commands (added by active mods)
3. Custom commands (.commandcode/commands/, ~/.commandcode/commands/)
4. Skills

So a custom command can never override a built-in, and a skill shadowed by any of the above resolves to its owner. Shadowed skills still render in the menu with a - shadowed by /<name> note so you know they exist, and they run under the skill: namespace: /skill:<name> bypasses this whole ladder and only ever resolves to a skill. Lookup is case-insensitive (/Reload resolves to /reload).

Skill invocation

Installed skills are invocable as /<skill-name> and appear in the menu with a [skill] badge. A skill's argument-hint frontmatter leads its menu description (e.g. /pr-desc [skill] <branch> - Generate a PR…), and skills marked user-invocable: false stay model-invocable but never appear in the / menu. Duplicate skill names dedupe with project taking precedence over global.

Mod commands

Active mods can register their own slash commands; they slot in between built-ins and custom commands in both the menu and dispatch. Discovery is fault-tolerant - a broken commands directory or unreadable skill never breaks the menu; each source just degrades to empty.

Next steps

• Explore the CLI Reference for flags and subcommands
• Create your first custom command and try it out
• Join our Discord community for feedback, requests, and support.