Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks

This is a working reference for the Claude Code commands surface as it stands in 2026, written for the person who has to govern it as well as use it. Every table below is the command list plus the thing a security-minded reader actually wants to know: what it changes, and whether it can quietly widen what the agent is allowed to do.

If you want the reasoning rather than the reference, the companion pieces are how Claude Code permissions actually work, the permissions and hooks hardening guide, and what shipped in 2026 and why it matters. The Codex equivalent of this page is the OpenAI Codex commands cheat sheet.

Starting and resuming sessions

Session, agent, and daemon management

Auth, setup, and diagnostics

Permission modes: the flag that matters most

--permission-mode decides whether a human ever sees the tool call. This is the first thing to check on any endpoint, and the first thing to pin in managed settings.

--dangerously-skip-permissions is the equivalent of --permission-mode bypassPermissions. A separate flag, --allow-dangerously-skip-permissions, adds bypassPermissions to the Shift+Tab mode cycle without starting in it - worth knowing, because it means a session that started safely can be cycled into bypass by hand. We walk the real behavior in what dangerously-skip-permissions actually does.

Flags that change the trust boundary

The sideload flags deserve a specific note. --plugin-url fetches a plugin archive from a URL for the session, and a plugin can bundle skills, subagents, hooks, and MCP server definitions in one unit. Admins can shut this class off with disableSideloadFlags in managed settings.

Slash commands: session control

Slash commands: configuration and security

/security-review and /code-review are genuinely useful and they operate on the diff, before code runs. They do not see what the agent does at runtime on the endpoint. That gap is the subject of scan-time versus runtime governance.

Bundled skills and workflows

Some slash commands are not built into the CLI - they are bundled skills or workflows, which means they load instructions into the turn and can fan work out across subagents. Custom commands and skills have converged: a file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy.

/fewer-permission-prompts is worth flagging for a governance reader. It does exactly what it says - it reduces friction by proposing allowlist entries - which is convenient for the developer and is, by definition, a policy-loosening operation. It belongs behind managed permission rules, not left to per-developer judgment.

Hook events: where enforcement actually lives

There are 31 hook events in 2026. How Claude Code hooks work explains the lifecycle and matcher syntax behind them. These are the ones that matter most for control, and the exit-code semantics that make them work.

Exit code semantics are simple and worth memorizing. Exit 0: success, and stdout is parsed for JSON output. Exit 2: blocking error - stdout is ignored, stderr is fed back to Claude as the reason. Any other code: non-blocking error; the action proceeds and a hook-error notice appears.

A PreToolUse hook returns its decision as JSON. The four values are allow, deny, ask, and defer, and updatedInput can rewrite the tool arguments before execution.

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Outbound push to non-allowlisted remote blocked by policy"
  }
}

The critical 2026 detail: auto mode can no longer override a hook's ask decision. A hook returning ask floors the decision at a prompt. That is precisely why enforcement belongs at the hook rather than at the permission prompt - the hook is the one control the classifier cannot talk its way past.

Settings precedence and managed policy

Precedence runs highest to lowest: managed, then command-line arguments, then local, then project, then user. Managed policy beating command-line flags is the whole reason managed settings are the enterprise control point.

The legacy Windows path C:\ProgramData\ClaudeCode\managed-settings.json stopped being supported in v2.1.75. If your MDM baseline predates that, the policy you think is deployed may not be loading at all - which is exactly the kind of silent gap worth verifying per endpoint rather than assuming.

Managed-only settings worth knowing

What to alert on

If you are building detections rather than reading this as a user, these are the signals that change what the agent is allowed to do:

• --dangerously-skip-permissions or --permission-mode bypassPermissions on any endpoint, and --allow-dangerously-skip-permissions, which makes bypass reachable via Shift+Tab.
• --bare or --safe-mode, which skip hook and plugin discovery - meaning they skip your enforcement along with everything else.
• --plugin-url or --plugin-dir, sideloading a bundle that never passed a marketplace check.
• --setting-sources dropping project, which discards repo-committed policy.
• setup-token generating a long-lived OAuth credential for CI.
• A Claude Code version outside your pinned range, since isolation and sandbox semantics changed repeatedly through 2026.
• Managed settings absent entirely, which is the quiet failure: an unenrolled laptop has none of the controls above.

Where Anomity fits

Everything on this page is a per-endpoint fact. The flags are typed on one laptop, the hooks live next to the settings that register them, and the managed policy only applies where it was received. Anomity's lightweight, unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - so "which permission mode, which version, which plugins, which hooks" becomes a query instead of a survey (fleet inventory).

At the PreToolUse hook, Anomity returns allow, deny, or log on each tool call before it runs, which turns an in-session approval or an auto-mode classifier decision into enforced org-wide policy (runtime governance). The Sensor sends metadata only over HTTPS, never source or prompts, with secrets redacted on the endpoint. Every decision lands in a queryable 90-day audit trail routed to your SIEM, Slack, email, or Jira (audit and outcomes). Anomity is SOC 2 Type II and complements your EDR, XDR, DLP, network, and GRC controls.

You can't govern what you can't see.

Bookmark this page as the command reference; the governance argument behind it is in deploying Claude Code across a fleet and auditing Claude Code across a fleet. If you want these facts inventoried across every endpoint instead of checked by hand, book a 30-minute demo.