Analyzed: March 31, 2026 leak snapshot
This page covers the slash command framework. Individual commands should be documented on separate reference pages once the command inventory is written.

​
What counts as a command

Claude Code uses slash commands as a second control plane beside natural-language prompts. Natural language goes through the model first. Slash commands go through the command registry first. That distinction matters because commands can:
  • Open local UI
  • Mutate session settings
  • Expand into prompt text
  • Execute entirely without the model
The registry entrypoint is src/commands.ts.

​
Command types

The codebase uses three main command shapes:
  • prompt: expands into text that is sent to the model
  • local: runs locally and returns text
  • local-jsx: renders Ink UI components in the terminal
That is the cleanest mental model for the command system. If a command needs a picker, dialog, or settings screen, it tends to be local-jsx. If it needs the model, it is prompt.

​
Registry architecture

src/commands.ts is the aggregator for built-in commands and external sources. It imports built-ins directly, then merges additional command sources at runtime:
  • Built-in commands
  • Skill directory commands
  • Bundled skills
  • Plugin commands
  • Plugin skills
  • Workflow commands
  • Dynamic skills discovered during execution
This is why the command list is memoized per working directory instead of being a fixed static array.

​
Loading flow

​
Availability and enablement

A command can be filtered out in two separate ways. Availability:
  • Provider or account requirements such as claude-ai or console
  • Evaluated on every getCommands() call because auth state can change mid-session
Enablement:
  • Feature gating and command-specific runtime checks
  • Evaluated after availability
This ordering is visible in meetsAvailabilityRequirement() and getCommands().

​
Commands versus skills

The codebase intentionally blurs the boundary between commands and skills.
  • Some prompt commands are model-invocable through the skill tool path
  • Some slash commands exist mainly as user-facing wrappers around skills
  • Skills from directories, plugins, bundled assets, and MCP can all become command-like entries
Two exported helpers in src/commands.ts make the split explicit:
  • getSkillToolCommands(): prompt-based commands the model may invoke
  • getSlashCommandToolSkills(): the subset treated as slash-command-style skills
This is one of the more important implementation details in the whole repo. The slash command surface is not just a UI convenience; it is also a capability catalog for the agent.

​
Remote and bridge safety

Not every slash command is safe in every transport. The registry defines explicit allowlists for:
  • Remote mode
  • Remote-control bridge mode
The reasoning is straightforward:
  • local-jsx commands cannot safely render UI on remote clients
  • Some local commands depend on local filesystem or terminal context
  • Prompt commands are usually safer because they expand into model text instead of executing local UI
The code handles this with REMOTE_SAFE_COMMANDS, BRIDGE_SAFE_COMMANDS, and isBridgeSafeCommand().

​
Execution path

Once a user enters /something, the input path differs from normal prompt handling:
  1. Parse the slash command token.
  2. Resolve the command from the active registry.
  3. Dispatch based on command type.
  4. Return local output, render UI, or synthesize prompt text.
  5. If prompt-based, continue into the normal model loop.
This split is one reason command handling lives near input processing instead of inside the model loop itself.

​
Feature-flagged commands

The registry uses bun:bundle feature gates heavily. Examples in src/commands.ts include:
  • Voice mode
  • Bridge mode
  • Ultraplan
  • Forked subagent flows
  • Internal Anthropic-only command surfaces
This means a command may exist in source but disappear entirely from specific builds.
When documenting command availability, source presence is not enough. Feature flags and account state can remove commands at runtime or at build time.

​
Naming and source annotation

Commands carry origin metadata used in UI and discovery surfaces. For prompt commands, the source can be:
  • Built-in
  • Plugin
  • Bundled
  • Skills directory
  • Legacy commands directory
  • MCP
formatDescriptionWithSource() uses that metadata to explain provenance in user-facing interfaces.

​
Why the system is structured this way

The command layer solves three different problems at once:
  • Power-user shortcuts for the terminal UI
  • Capability discovery for the model
  • Extensibility for plugins, workflows, skills, and MCP
That is why src/commands.ts looks more like a routing and policy module than a simple command list.