--- title: "Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks" description: "A complete 2026 Claude Code commands cheat sheet - CLI commands, flags, slash commands, permission modes, hook events, and managed settings - with the security note on each." url: "https://anomity.ai/blog/claude-code-commands-cheat-sheet/" source: html --- On this page - Starting and resuming sessions - Session, agent, and daemon management - Auth, setup, and diagnostics - Permission modes: the flag that matters most - Flags that change the trust boundary - Slash commands: session control - Slash commands: configuration and security - Bundled skills and workflows - Hook events: where enforcement actually lives - Settings precedence and managed policy - Managed-only settings worth knowing - What to alert on - Where Anomity fits - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks ![Anomity robot illustrating Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks] Guide # Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks Anomity Research Anomity Research · Aug 8, 2026 · 6 min read Share: Copied TL;DR - This Claude Code commands cheat sheet covers the 2026 surface: CLI commands and flags, every built-in slash command, permission modes, hook events, and the managed settings that override all of them. - Permission modes are the single most important thing to know: --permission-mode accepts default , manual , acceptEdits , plan , auto , dontAsk , and bypassPermissions , and the choice decides whether a human sees the tool call at all. - auto mode hands the approval decision to a permission classifier instead of a prompt. A PreToolUse hook returning ask still floors the decision at a prompt, which is why the hook, not the prompt, is where enforcement belongs. - Hooks are the enforcement point. PreToolUse returns allow , deny , ask , or defer before a tool runs, and exit code 2 blocks. Thirty-one hook events exist as of 2026. - Managed settings win over everything , including command-line flags - and allowManagedPermissionRulesOnly , allowManagedHooksOnly , and allowManagedMcpServersOnly stop a developer from loosening policy locally. - The flags worth alerting on: --dangerously-skip-permissions , --permission-mode bypassPermissions , --tools , --settings , --plugin-url , and --bare . 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. A reference like this is only useful while it is accurate, so we track Claude Code releases deliberately rather than opportunistically - one of the reasons we joined [Claude for Startups](https://anomity.ai/blog/anomity-claude-for-startups/). If you want the reasoning rather than the reference, the companion pieces are [how Claude Code permissions actually work](https://anomity.ai/blog/how-claude-code-permissions-work/), [the permissions and hooks hardening guide](https://anomity.ai/blog/claude-code-permissions-hooks-hardening-guide/), and [what shipped in 2026 and why it matters](https://anomity.ai/blog/new-claude-code-features-2026-security/). The Codex equivalent of this page is [the OpenAI Codex commands cheat sheet](https://anomity.ai/blog/openai-codex-commands-cheat-sheet/). ## Starting and resuming sessions Command What it does `claude` Start an interactive session `claude "query"` Start interactive with an initial prompt `claude -p "query"` Print mode: run headless, then exit `cat file \| claude -p "query"` Pipe content in and process it `claude -c` Continue the most recent conversation in this directory `claude -r " " "query"` Resume a session by ID or name `claude --fork-session` On resume, create a new session ID instead of reusing the original `claude --bg "query"` Start as a background agent and return immediately `claude --teleport` Pull a web session down into this terminal `claude --cloud "query"` Create or target a web session on claude.ai ## Session, agent, and daemon management Command What it does `claude agents` Open the agent view for parallel background sessions `claude attach ` Attach to a background session in this terminal `claude logs ` Print recent output from a background session `claude stop ` / `claude kill ` Stop a background session `claude respawn ` Restart a background session with the conversation intact `claude rm ` Remove a background session from the list `claude daemon status` Print the background-session supervisor's state `claude daemon stop --any` Stop the supervisor and hosted sessions `claude project purge [path]` Delete all local Claude Code state for a project ## Auth, setup, and diagnostics Command What it does Security note `claude auth login` / `logout` / `status` Manage the Anthropic account session `status` returns JSON - useful for fleet checks `claude setup-token` Generate a long-lived OAuth token for CI and scripts A long-lived credential; treat it as a secret to inventory `claude doctor` Print installation and settings diagnostics Fastest way to see what config is actually live `claude update` / `claude install [version]` Update or reinstall the binary Version pins matter: isolation semantics are version-dependent `claude import [codex\|gemini]` Import configuration from another coding agent Pulls another tool's config in; run with `--dry-run` first `claude remote-control` Start the Remote Control server Lets another device approve prompts for this session `claude self-hosted-runner` Turn this host into an execution environment for web, mobile, and desktop sessions (Team/Enterprise) A long-lived host accepting work initiated elsewhere `claude mcp` / `claude plugin` Manage MCP servers and plugins Both add artifacts you want inventoried ## 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. Mode Behavior Governance posture `default` / `manual` Prompt for approval on tool use; "Manual" is the 2026 display name with a grey badge in the footer The safe floor for attended work `plan` Plan first, no edits or commands until you accept Good default for exploring an unfamiliar repo `acceptEdits` File edits auto-accept; commands still prompt Reasonable for attended refactors `auto` A permission classifier adjudicates instead of prompting you The approval decision moved from a person to a model `dontAsk` Suppress prompts without full bypass Verify what it still blocks before allowing it `bypassPermissions` Skip permission prompts entirely Treat as a break-glass mode; alert on it `--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](https://anomity.ai/blog/claude-code-dangerously-skip-permissions-explained/). ## Flags that change the trust boundary Flag What it does Why it matters `--allowedTools` / `--disallowedTools` Allow or deny rules for tools, e.g. `"Bash(git log *)"` Per-session policy that a managed rule should be able to override `--tools` Restrict which built-in tools Claude can use A tightening flag - useful in CI `--add-dir` Add working directories Claude can read and edit Widens the filesystem blast radius `--settings` Load a settings JSON file or inline JSON Can carry sandbox and credential-masking config `--setting-sources` Choose which scopes to load (user, project, local) Can drop project policy from the session `--mcp-config` / `--strict-mcp-config` Load MCP servers from files; ignore all others `--strict-mcp-config` is a hardening flag, not a risk `--plugin-dir` / `--plugin-url` Load a plugin from a directory or a URL for this session Sideloads a bundle with no marketplace review `--bare` Skip auto-discovery of hooks, skills, plugins, MCP, and CLAUDE.md Also skips your hooks - so it skips your enforcement `--safe-mode` Start with all customizations disabled Troubleshooting; same caveat as `--bare` `--system-prompt` / `--append-system-prompt` Replace or extend the system prompt Changes agent behavior outside any policy file `--max-budget-usd` Stop after a dollar amount of API spend Also halts running background subagents `--effort` Set effort: low, medium, high, xhigh, max, ultracode Higher effort means more autonomous work per turn 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. Marketplace installs carry their own risk: [Plugin4Shell](https://anomity.ai/blog/plugin4shell-coding-agent-plugin-sha-pinning-bypass/) showed that a pinned plugin commit could be bypassed in agents that never verified what they checked out. ## Slash commands: session control Command What it does `/help` Show help and available commands `/clear`, `/new`, `/reset` Start a new conversation with empty context `/compact [instructions]` Summarize the conversation to free context `/context [all]` Visualize current context usage as a grid `/autocompact [auto\| ]` Set the auto-compact window `/resume [session-id\|name]` Return to an earlier conversation `/rewind [message-count\|from-turn]` Roll code and conversation back to a checkpoint `/fork [prompt]` Copy the conversation into a new background session `/branch [name]` Create a branch of the current conversation `/background [prompt]` Detach the session to run as a background agent `/subtask [prompt]` Hand a side task to a subagent `/tasks` List the session's background work `/status` Show current session status `/usage`, `/cost` Show token and cost metrics `/export [filename]` Export the conversation as plain text `/diff` Open an interactive diff viewer for uncommitted changes `/exit`, `/quit` Exit the CLI ## Slash commands: configuration and security Command What it does Security relevance `/permissions` Set approval rules for file access and tool use The in-session view of allow/deny/ask rules `/hooks` View hook configurations for tool events Confirm your `PreToolUse` hook is actually registered `/config`, `/settings` Open settings or set a preference directly Shows what is live, including managed overrides `/doctor` Run a setup checkup that diagnoses and fixes issues Surfaces config drift `/mcp` Manage MCP servers, connections, and OAuth Each server is an artifact and an egress path `/plugins` Manage plugins One plugin expands into many artifacts `/skills` Manage custom skills Skills can auto-load without a prompt `/agents` Manage subagent configurations Each subagent is another autonomous actor `/list-agents` List subagents and sessions Claude can message The cross-session messaging surface `/memory` Edit `CLAUDE.md` memory files and auto-memory Instructions that persist across sessions `/model`, `/effort`, `/fast` Switch model, effort level, fast mode Capability changes under a policy set earlier `/remote-control [connect\|disconnect]` Continue a local session from another device Approvals can be answered off-machine `/security-review` Check the diff for security vulnerabilities Scan-time, not runtime - see the distinction below `/login`, `/logout` Sign in or out of the Anthropic account `forceLoginOrgUUID` can pin the org `/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](https://anomity.ai/blog/claude-security-scan-time-vs-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`. A subagent runs in its own context and returns only its answer, so [what a subagent leaves in the parent transcript and what it discards](https://anomity.ai/blog/claude-code-session-efficiency-audit-trail/) decides how much of that work anyone can reconstruct later. Command Type What it does `/code-review [level] [--fix] [--comment] [target]` Skill Review the diff, a PR, a branch, or a path `/review` Alias Alias for `/code-review` `/security-review` Skill Check the diff for security vulnerabilities `/verify` Skill Verify code correctness without applying changes `/simplify [--fix]` Skill Suggest simplifications to recent code `/test ` Skill Write, run, and debug tests `/debug [description]` Skill Enable debug logging and troubleshoot `/batch ` Skill Orchestrate large-scale changes in parallel `/loop [interval] [prompt]` Skill Run a prompt repeatedly while the session stays open `/deep-research ` Workflow Fan out web searches and synthesize a cited report `/fewer-permission-prompts` Skill Scan transcripts and propose an allowlist `/doctor` Skill Setup checkup that diagnoses and fixes issues `/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](https://anomity.ai/blog/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. Event When it fires Can block? `PreToolUse` Before a tool call executes Yes - blocks the call `PermissionRequest` When a tool call needs a permission decision Yes - denies it `PermissionDenied` When the auto mode classifier denies a call No - use JSON `retry: true` `UserPromptSubmit` When you submit a prompt, before Claude sees it Yes - blocks and erases the prompt `SessionStart` / `SessionEnd` Session begins or resumes / terminates No `SubagentStart` / `SubagentStop` A subagent is spawned / finishes Stop can block `PostToolUse` / `PostToolUseFailure` After a tool call succeeds / fails No - it already ran `PostToolBatch` After a batch of parallel calls resolves Yes - stops the agentic loop `ConfigChange` A configuration file changes mid-session Yes (except policy_settings) `InstructionsLoaded` A `CLAUDE.md` or `.claude/rules/*.md` loads into context No `WorktreeCreate` / `WorktreeRemove` A worktree is created / removed Any non-zero exit fails creation `TeammateIdle` An agent team teammate is about to go idle Yes 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. Platform Managed settings path macOS `/Library/Application Support/ClaudeCode/managed-settings.json` (plus `managed-settings.d/*.json`, and the `com.anthropic.claudecode` managed preferences domain) Linux and WSL `/etc/claude-code/managed-settings.json` (plus `managed-settings.d/*.json`) Windows `C:\Program Files\ClaudeCode\managed-settings.json`, plus `HKLM\SOFTWARE\Policies\ClaudeCode` via Group Policy or Intune 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 Setting Effect `allowManagedPermissionRulesOnly` User and project settings cannot define permission rules `allowManagedHooksOnly` Only managed and SDK hooks load `allowManagedMcpServersOnly` Only managed MCP servers connect `allowedMcpServers` / `deniedMcpServers` Explicit MCP allow and deny lists `disableSideloadFlags` Blocks `--plugin-dir` and `--plugin-url` style sideloading `strictKnownMarketplaces` / `blockedMarketplaces` Marketplace allow/block, including `"owner/*"` org wildcards `requiredMinimumVersion` / `requiredMaximumVersion` Pin the acceptable Claude Code version range `forceLoginOrgUUID` Restrict login to a specific organization `sandbox.credentials` / `sandbox.filesystem` Credential masking and filesystem isolation `crossSessionInbound` / `dialogExpiry` Control inbound cross-session messages ## 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](https://anomity.ai/#features)). 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](https://anomity.ai/#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](https://anomity.ai/#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](https://anomity.ai/blog/deploying-claude-code-across-a-fleet-guide/) and [auditing Claude Code across a fleet](https://anomity.ai/blog/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](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What are the Claude Code permission modes? The --permission-mode flag accepts default, manual, acceptEdits, plan, auto, dontAsk, and bypassPermissions. Default and manual prompt for approval on tool use; plan holds off on edits and commands until you accept; acceptEdits auto-accepts file edits while commands still prompt; auto hands the decision to a permission classifier instead of prompting; dontAsk suppresses prompts without full bypass; and bypassPermissions skips prompts entirely. The mode is the single most important fact to know about any Claude Code endpoint. How do I block a tool call in Claude Code? Use a PreToolUse hook. It fires before a tool call executes and returns a JSON decision of allow, deny, ask, or defer in hookSpecificOutput, with permissionDecisionReason shown to Claude. Exiting the hook with code 2 also blocks, and stderr is fed back as the reason. As of 2026 auto mode cannot override a hook's ask decision, so a hook returning ask forces a prompt. That is why the hook, not the permission prompt, is the reliable place to enforce policy. Which Claude Code flags should security teams alert on? --dangerously-skip-permissions and --permission-mode bypassPermissions skip prompts entirely, and --allow-dangerously-skip-permissions makes bypass reachable through the Shift+Tab mode cycle. --bare and --safe-mode skip auto-discovery of hooks, skills, plugins, and MCP servers, which means they skip your enforcement too. --plugin-url and --plugin-dir sideload plugin bundles without a marketplace check. --setting-sources can drop project-scoped policy from the session. Admins can disable the sideload class with disableSideloadFlags in managed settings. Where does Claude Code load managed settings from? On macOS, /Library/Application Support/ClaudeCode/managed-settings.json plus managed-settings.d/*.json and the com.anthropic.claudecode managed preferences domain. On Linux and WSL, /etc/claude-code/managed-settings.json plus managed-settings.d/*.json. On Windows, C:\Program Files\ClaudeCode\managed-settings.json plus HKLM\SOFTWARE\Policies\ClaudeCode via Group Policy or Intune. The legacy Windows path C:\ProgramData\ClaudeCode\managed-settings.json stopped being supported in v2.1.75, so an older MDM baseline may be deploying policy that never loads. What is the Claude Code settings precedence order? Highest to lowest: managed settings, then command-line arguments, then local settings, then project settings, then user settings. Managed policy beating command-line flags is what makes it the enterprise control point, since a developer cannot loosen it with a flag. Managed-only settings extend this further: allowManagedPermissionRulesOnly stops user and project scopes from defining permission rules, allowManagedHooksOnly restricts hook loading, and allowManagedMcpServersOnly restricts which MCP servers may connect. Are Claude Code slash commands the same as skills? 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 and work the same way. Some built-in slash commands are coded into the CLI, while others such as /code-review, /security-review, /verify, /test, and /batch are bundled skills, and /deep-research is a workflow that fans work across subagents. The security consequence is that a slash command can load instructions into the turn, and a skill can auto-load when Claude judges it relevant rather than only when you type its name. Does /security-review cover runtime risk? No, and the distinction matters. /security-review and /code-review operate on the diff, before code runs, which makes them scan-time controls. They do not see what the agent does at runtime on the endpoint: which commands it executes, which MCP servers it reaches, or which files it touches outside the diff. Runtime governance happens at the PreToolUse hook, where a decision is returned before the tool call executes, and in the audit trail that records what was actually allowed. ## Related [Guide ### Claude Code Security Review GitHub Action: A Hardened Setup Guide (2026) Anthropic's AI security review action is useful and, in its own words, not hardened against prompt injection. How to deploy it without adding a hole. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/claude-code-security-review-github-action-guide/) [Guide ### NVIDIA OpenShell: A Security Team's Guide to the Agent Sandbox and Its Defaults (2026) How NVIDIA OpenShell sandboxes AI agents, what its policy engine enforces, and the defaults to change before you rely on it: audit mode, Landlock, logs. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/nvidia-openshell-agent-sandbox-security-guide/) [Guide ### Enterprise-Managed MCP Connectors: What IdP-Governed Authorization Covers, and What It Does Not (2026) Enterprise-managed MCP connectors went GA on 24 August 2026 across ten connectors. What IdP-governed authorization covers, and what it cannot see. Anomity Research · Aug 27, 2026 · 9 min](https://anomity.ai/blog/anthropic-enterprise-managed-mcp-connectors-idp-governance/) ## Structured data ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks", "description": "A complete 2026 Claude Code commands cheat sheet - CLI commands, flags, slash commands, permission modes, hook events, and managed settings - with the security note on each.", "datePublished": "2026-08-08", "dateModified": "2026-08-08", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/claude-code-commands-cheat-sheet/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/posts/claude-code-commands-cheat-sheet.jpg", "width": 1200, "height": 630 }, "articleSection": "Guide", "url": "https://anomity.ai/blog/claude-code-commands-cheat-sheet/", "keywords": "Claude Code commands cheat sheet, Claude Code, CLI reference, slash commands, hooks, permission modes, managed settings" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What are the Claude Code permission modes?", "acceptedAnswer": { "@type": "Answer", "text": "The --permission-mode flag accepts default, manual, acceptEdits, plan, auto, dontAsk, and bypassPermissions. Default and manual prompt for approval on tool use; plan holds off on edits and commands until you accept; acceptEdits auto-accepts file edits while commands still prompt; auto hands the decision to a permission classifier instead of prompting; dontAsk suppresses prompts without full bypass; and bypassPermissions skips prompts entirely. The mode is the single most important fact to know about any Claude Code endpoint." } }, { "@type": "Question", "name": "How do I block a tool call in Claude Code?", "acceptedAnswer": { "@type": "Answer", "text": "Use a PreToolUse hook. It fires before a tool call executes and returns a JSON decision of allow, deny, ask, or defer in hookSpecificOutput, with permissionDecisionReason shown to Claude. Exiting the hook with code 2 also blocks, and stderr is fed back as the reason. As of 2026 auto mode cannot override a hook's ask decision, so a hook returning ask forces a prompt. That is why the hook, not the permission prompt, is the reliable place to enforce policy." } }, { "@type": "Question", "name": "Which Claude Code flags should security teams alert on?", "acceptedAnswer": { "@type": "Answer", "text": "--dangerously-skip-permissions and --permission-mode bypassPermissions skip prompts entirely, and --allow-dangerously-skip-permissions makes bypass reachable through the Shift+Tab mode cycle. --bare and --safe-mode skip auto-discovery of hooks, skills, plugins, and MCP servers, which means they skip your enforcement too. --plugin-url and --plugin-dir sideload plugin bundles without a marketplace check. --setting-sources can drop project-scoped policy from the session. Admins can disable the sideload class with disableSideloadFlags in managed settings." } }, { "@type": "Question", "name": "Where does Claude Code load managed settings from?", "acceptedAnswer": { "@type": "Answer", "text": "On macOS, /Library/Application Support/ClaudeCode/managed-settings.json plus managed-settings.d/*.json and the com.anthropic.claudecode managed preferences domain. On Linux and WSL, /etc/claude-code/managed-settings.json plus managed-settings.d/*.json. On Windows, C:\\Program Files\\ClaudeCode\\managed-settings.json plus HKLM\\SOFTWARE\\Policies\\ClaudeCode via Group Policy or Intune. The legacy Windows path C:\\ProgramData\\ClaudeCode\\managed-settings.json stopped being supported in v2.1.75, so an older MDM baseline may be deploying policy that never loads." } }, { "@type": "Question", "name": "What is the Claude Code settings precedence order?", "acceptedAnswer": { "@type": "Answer", "text": "Highest to lowest: managed settings, then command-line arguments, then local settings, then project settings, then user settings. Managed policy beating command-line flags is what makes it the enterprise control point, since a developer cannot loosen it with a flag. Managed-only settings extend this further: allowManagedPermissionRulesOnly stops user and project scopes from defining permission rules, allowManagedHooksOnly restricts hook loading, and allowManagedMcpServersOnly restricts which MCP servers may connect." } }, { "@type": "Question", "name": "Are Claude Code slash commands the same as skills?", "acceptedAnswer": { "@type": "Answer", "text": "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 and work the same way. Some built-in slash commands are coded into the CLI, while others such as /code-review, /security-review, /verify, /test, and /batch are bundled skills, and /deep-research is a workflow that fans work across subagents. The security consequence is that a slash command can load instructions into the turn, and a skill can auto-load when Claude judges it relevant rather than only when you type its name." } }, { "@type": "Question", "name": "Does /security-review cover runtime risk?", "acceptedAnswer": { "@type": "Answer", "text": "No, and the distinction matters. /security-review and /code-review operate on the diff, before code runs, which makes them scan-time controls. They do not see what the agent does at runtime on the endpoint: which commands it executes, which MCP servers it reaches, or which files it touches outside the diff. Runtime governance happens at the PreToolUse hook, where a decision is returned before the tool call executes, and in the audit trail that records what was actually allowed." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Claude Code Commands Cheat Sheet (2026): CLI, Slash Commands, Flags, and Hooks", "item": "https://anomity.ai/blog/claude-code-commands-cheat-sheet/" } ] } ```