Claude Code Insider - Tygart Media

Category: Claude Code Insider

Practitioner-level guides, comparisons, workflows, and real-world patterns for Claude Code — the agentic AI coding tool from Anthropic.

  • How to Connect Any Tool to Claude with MCP: Complete Setup Guide

    How to Connect Any Tool to Claude with MCP: Complete Setup Guide

    Last verified: October 8, 2026 (Pacific)

    MCP (Model Context Protocol) is how you give Claude hands. Out of the box Claude can talk; with an MCP server connected, it can read your files, query a database, hit an API, or drive a browser. This guide covers the two places you actually wire servers up: the claude_desktop_config.json file for the Claude Desktop app, and the claude mcp add command for Claude Code (the terminal/IDE tool). It ends with the troubleshooting section the official docs skip: path problems, JSON syntax traps, servers that silently never load, and the Windows quirks that cost people an afternoon.

    Everything below is checked against the current Claude Code MCP docs and tested commands. If you want the wider picture of how MCP fits into a working setup, see the AI operator’s stack.

    What is MCP and what is an MCP server?

    Flow from app/IDE through MCP to servers and data APIs
    What MCP is — and what an MCP server is.

    MCP transport options at a glance

    TransportUse caseConfig locationWorks with
    stdioLocal tools, CLIs, scriptsclaude_desktop_config.json or claude mcp addClaude Desktop, Claude Code
    SSE (HTTP)Remote servers, cloud servicesURL in configClaude Desktop, Claude Code
    Streamable HTTPProduction remote MCPURL in configClaude Desktop, Claude Code

    MCP is an open standard for connecting AI models to external tools and data. An MCP server is a small program that exposes a set of tools (functions Claude can call) over that protocol. Claude is the client; the server is the thing that actually does the work, like reading a Postgres table or creating a GitHub issue.

    There are two transport types you will deal with in practice:

    • stdio (local): the server runs as a process on your machine. Claude talks to it over standard input/output. Best for filesystem access, local databases, and custom scripts. This is what most “install this MCP server” instructions mean.
    • HTTP (remote): the server lives on the internet at a URL. Best for cloud services (Notion, Sentry, Stripe, GitHub). Often uses OAuth. SSE is the older remote transport and is now deprecated; use HTTP for new remote servers.

    The same server can usually be added to both Claude Desktop and Claude Code. The mechanics differ: Desktop uses a JSON file you edit by hand, Claude Code gives you a CLI that writes the config for you.

    How do I add an MCP server to Claude Desktop?

    Five-step path: account, API keys, billing, usage, workspaces
    Add an MCP server to Claude Desktop.

    For local stdio servers, Claude Desktop still reads a single JSON file — you edit it, fully quit the app, and reopen. The config file remains the source of truth for anything that runs on your own machine. Remote servers are a different story: Claude Desktop now offers an in-app route (Settings > Connectors > Add custom connector) that adds a remote server by URL and handles OAuth for you.

    Where is claude_desktop_config.json?

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
    • Windows: %APPDATA%\Claude\claude_desktop_config.json (paste that into the File Explorer address bar; it expands to C:\Users\YOU\AppData\Roaming\Claude\)

    The fastest way to open it: in Claude Desktop go to Settings > Developer > Edit Config. That button creates the file if it does not exist and opens the folder. If the file is brand new it may be empty or just {}.

    The config file structure

    Everything lives under a top-level mcpServers object. Each key is a name you choose; each value describes how to launch the server. Here is a complete, working file with a local filesystem server and a remote Notion server:

    {
      "mcpServers": {
        "filesystem": {
          "command": "npx",
          "args": [
            "-y",
            "@modelcontextprotocol/server-filesystem",
            "C:\\Users\\YOU\\Documents"
          ]
        },
        "notion": {
          "command": "npx",
          "args": ["-y", "@notionhq/notion-mcp-server"],
          "env": {
            "NOTION_TOKEN": "secret_your_token_here"
          }
        }
      }
    }

    Three fields do all the work:

    • command the executable to run (npx, node, python, uvx, or an absolute path to a binary).
    • args an array of arguments. Each flag and value is its own array element. "--port 8080" as a single string will not work; use "--port", "8080".
    • env an object of environment variables (API keys, tokens). Optional.

    After saving, completely quit Claude Desktop (on Windows, right-click the system tray icon and choose Quit; closing the window is not enough) and reopen it. You should see a tools/connector indicator in the chat input. For a full Notion walkthrough including the token, see connecting Notion to Claude with MCP.

    How do I add an MCP server to Claude Code (CLI)?

    Side-by-side cards defining what Claude Code is and is not
    Add an MCP server to Claude Code CLI.

    Claude Code does not make you hand-edit JSON. The claude mcp command manages servers for you and writes to the right file. This is the part people get wrong most often, so here is the exact, verified syntax.

    claude mcp add

    The general form for a local (stdio) server is:

    claude mcp add [options] <name> -- <command> [args...]

    The -- is load-bearing. Everything before it is for Claude Code; everything after it is the command that launches your server. Real examples:

    # Local filesystem server
    claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/Documents
    
    # Local server with an environment variable
    claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY airtable -- npx -y airtable-mcp-server
    
    # Remote HTTP server
    claude mcp add --transport http notion https://mcp.notion.com/mcp
    
    # Remote HTTP server with an auth header
    claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer YOUR_PAT"

    Option ordering matters. All flags (--transport, --env, --scope, --header) must come before the server name. Put a flag after the name and you will get a confusing parse error or the flag will be passed to your server instead of to Claude Code.

    Scopes: local, project, user

    The --scope flag decides where the config is written and who sees it:

    • local (the default) loads only in the current project, private to you. Stored in ~/.claude.json keyed by the project path.
    • project loads in the current project and is shared with your team. Stored in a .mcp.json file at the project root that you commit to git.
    • user loads across all your projects, private to you. Also stored in ~/.claude.json.
    # Available across all your projects
    claude mcp add --scope user --transport http sentry https://mcp.sentry.dev/mcp
    
    # Shared with your team via .mcp.json in the repo
    claude mcp add --scope project filesystem -- npx -y @modelcontextprotocol/server-filesystem .

    When the same server name exists at multiple scopes, local wins over project, which wins over user. The whole entry from the winning scope is used; fields are not merged.

    claude mcp list, get, and remove

    # List every configured server and its connection status
    claude mcp list
    
    # Show the full config for one server
    claude mcp get github
    
    # Remove a server
    claude mcp remove github

    claude mcp list is your first diagnostic. It shows each server as connected, pending, or failed. Project-scoped servers from a .mcp.json you have not approved yet show as Pending approval until you run claude interactively and accept them.

    Other useful commands

    # Add from a raw JSON blob (handy when copying from a server's README)
    claude mcp add-json weather '{"type":"stdio","command":"npx","args":["-y","weather-mcp"]}'
    
    # Import everything you already set up in Claude Desktop (macOS / WSL)
    claude mcp add-from-claude-desktop

    Inside a running Claude Code session, type /mcp to see live server status, tool counts, and to trigger OAuth login for remote servers that need it.

    Troubleshooting: the errors the docs skip

    Most MCP failures are not exotic. They are paths, quoting, and the app not restarting. Work this list top to bottom.

    Server not loading / no tools appear

    1. Did you actually restart? Claude Desktop only reads the config at launch. Fully quit (tray icon > Quit on Windows, Cmd+Q on macOS) and reopen. In Claude Code, run claude mcp list to see the real status instead of guessing.
    2. Is the command on PATH? The single most common stdio failure is npx, node, python, or uvx not being found by the app. GUI apps often have a narrower PATH than your terminal. Fix it by using an absolute path. Find it with which npx (macOS/Linux) or where npx (Windows), then put that full path in command.
    3. Read the logs. Claude Desktop writes per-server logs. macOS: ~/Library/Logs/Claude/. Windows: %APPDATA%\Claude\logs\. Look for mcp-server-NAME.log. The actual error (missing module, bad token, wrong path) is almost always sitting right there.

    spawn ENOENT or “command not found”

    This means the OS could not find the executable named in command. It is a PATH problem, not a Claude problem. Use the absolute path (see above). On Windows specifically, see the npx note below.

    JSON syntax errors (the silent killer)

    If claude_desktop_config.json has a single syntax error, Claude Desktop loads zero servers and usually says nothing. The usual culprits:

    • Trailing commas. JSON forbids a comma after the last item in an object or array. "args": ["a", "b",] is invalid.
    • Smart quotes. If you edited the file in a word processor, curly quotes (the slanted kind) break the parser. Use a code editor and straight quotes only.
    • Unescaped Windows backslashes. In JSON, \ is an escape character, so every backslash in a Windows path must be doubled: C:\\Users\\YOU\\Documents. A single backslash silently corrupts the string.

    Paste the whole file into any JSON validator before restarting. Thirty seconds there saves an hour of staring.

    Claude Code: flag passed to the wrong place

    If claude mcp add behaves strangely, you almost certainly put a flag after the server name or forgot the --. Reread the order: claude mcp add [flags] NAME -- COMMAND ARGS. The -- separates Claude Code’s flags from your server’s command.

    Windows quirks

    • npx needs a wrapper in some setups. If a bare "command": "npx" fails on Windows, launch it through cmd: "command": "cmd" with "args": ["/c", "npx", "-y", "the-server-package"]. This resolves a class of “npx works in my terminal but not in Claude” failures.
    • Use the right config root. It is %APPDATA%\Claude\ (which is AppData\Roaming), not AppData\Local. Mixing these up means you are editing a file the app never reads.
    • Git Bash mangles paths. If you run commands through Git Bash, it can rewrite paths like /c/Users or absolute paths inside arguments. Prefer PowerShell or cmd for claude mcp add, or pass paths exactly as Windows expects them.
    • WSL is a separate world. A server installed inside WSL is not visible to a Windows-native Claude Desktop, and vice versa. Keep both on the same side.

    Remote server returns 401 / 403

    The server needs authentication. In Claude Code, run /mcp and complete the OAuth flow in your browser. If you hardcoded an Authorization header and it is rejected, the token is wrong for that endpoint; remove the header and let OAuth handle it instead.

    Frequently asked questions

    What is an MCP server in one sentence?

    A small program that exposes tools (functions like read-file or query-database) to Claude over the Model Context Protocol, so Claude can take real actions instead of only producing text.

    What is the difference between Claude Desktop and Claude Code for MCP?

    Claude Desktop is the chat app and you configure servers by hand-editing claude_desktop_config.json, then restarting. Claude Code is the terminal/IDE tool and you configure servers with the claude mcp add command, which writes the config for you.

    Where is the Claude Desktop config file?

    macOS: ~/Library/Application Support/Claude/claude_desktop_config.json. Windows: %APPDATA%\Claude\claude_desktop_config.json. The quickest way to open it is Settings > Developer > Edit Config inside the app.

    Why is my MCP server not showing up?

    In order of likelihood: you did not fully restart the app, the command is not on the app’s PATH (use an absolute path), or there is a JSON syntax error such as a trailing comma, a smart quote, or an unescaped Windows backslash. Check the per-server log in the Claude logs folder for the exact error.

    What does the double dash do in claude mcp add?

    The -- separates Claude Code’s own flags from the command that launches your server. Flags like --transport and --env go before it; the actual launch command (npx -y some-server) goes after it.

    What is the default scope for claude mcp add?

    local. The server loads only in the current project and stays private to you. Use --scope user to make it available in every project, or --scope project to share it with your team via a committed .mcp.json.

    Is SSE or HTTP the right transport for remote servers?

    HTTP. SSE still works but is deprecated. Use --transport http for any new remote server unless its documentation specifically requires SSE.

    How do I remove an MCP server?

    In Claude Code, run claude mcp remove NAME. In Claude Desktop, delete that server’s entry from the mcpServers object in claude_desktop_config.json and restart the app.

    Where to go next

    Once your servers connect cleanly, the leverage comes from using them well. For how this fits a daily workflow, read the AI operator’s stack; if you are choosing between coding environments, see Claude Code vs Cursor. And if you want a concrete first server to wire up, the Notion MCP setup is a clean, high-value place to start.

    Frequently Asked Questions

    What is MCP and why does it matter for Claude?

    MCP (Model Context Protocol) is an open standard that lets Claude connect to external tools, databases, APIs, and services. Without MCP, Claude can only work with text in the conversation window. With an MCP server connected, Claude can read your files, query a live database, hit an API, or control a browser — turning it from a chat interface into an autonomous agent.

    How do I add an MCP server to Claude Desktop?

    Edit the claude_desktop_config.json file (found at ~/Library/Application Support/Claude/ on Mac, %APPDATA%/Claude/ on Windows). Add your server under the ‘mcpServers’ key with a ‘command’, ‘args’, and optional ‘env’ block. Save the file and restart Claude Desktop. The server appears in Claude’s tool list if it loaded correctly.

    How do I add an MCP server to Claude Code?

    Run ‘claude mcp add [args…]’ from your terminal. For a remote SSE server use ‘claude mcp add –transport sse ‘. List configured servers with ‘claude mcp list’. Servers added this way are scoped to your user profile unless you use the –project flag.

    Why does my MCP server connect but Claude can’t see my data?

    The most common cause is scope or permission gaps. For Notion, verify your integration has been granted access to the specific pages/databases — the connection succeeds even without page access. For file servers, check that the path in your config resolves correctly from the shell Claude launches (not your interactive shell). For OAuth servers, re-authorize and confirm token scopes.

    What is the difference between stdio and SSE MCP transports?

    stdio runs the MCP server as a local subprocess — Claude launches the command you specify and communicates over stdin/stdout. This is used for local tools and CLIs. SSE (Server-Sent Events) connects to a remote HTTP server. Use stdio for local tools like filesystem access or database clients; use SSE or Streamable HTTP for cloud services or shared team servers.

    Which MCP servers should I start with?

    The highest-value first connections are: filesystem (read/write your local files), a database client for your primary DB, and a service you interact with daily (Notion, Slack, GitHub, Linear). The Notion MCP server is a clean first project — see the dedicated setup guide on this site for the exact config and common errors.

  • Local AI Without NPU: Turn a $400 Laptop Into an AI PC

    Local AI Without NPU: Turn a $400 Laptop Into an AI PC

    All fall, Microsoft has been selling one idea: the future is the AI PC — a Copilot+ machine with a dedicated neural chip (an NPU), Recall, Click to Do, a thousand dollars and up, and your old laptop need not apply.

    I had a $400 budget laptop on my desk — an AMD Ryzen 5 7520U, 16 GB of RAM, no NPU — and a hunch that the whole framing was backwards. The AI-first laptop was never about the chip. It’s about architecture.

    A few hours later, that $400 laptop had a private AI brain, voice control, and a control panel I run from my phone. On the things that actually matter for operating a machine, it does more than the Copilot+ PC it’s supposedly too cheap to be. Here’s the exact build.

    The thesis: AI-first is architecture, not a chip

    Five-step flow from files to chunk, embed, store, retrieve
    AI-first is architecture, not a chip.

    The trick is to stop asking your laptop to be the supercomputer. Split the job:

    • The brain lives in the cloud. The heavy reasoning runs on a frontier model (I use Claude) with effectively unlimited horsepower. No NPU on Earth competes with that.
    • The body lives on your laptop. Your machine becomes the always-on hands: it holds your private data, runs small models locally for anything sensitive, and executes the actions the brain decides on.

    An NPU optimizes a handful of on-device Windows features. Architecture gives you an actual operator. Guess which one you feel every day.

    Step 0 — Make it always-on

    An operator rig is a little server, and servers don’t nap. My laptop kept sleeping and killing background jobs, so the first move was to take that off the table (while plugged in):

    powercfg /change monitor-timeout-ac 0
    powercfg /change standby-timeout-ac 0
    powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 0
    powercfg /setactive SCHEME_CURRENT

    Screen never blanks, never sleeps, and it keeps running with the lid closed — while still sleeping on battery as a safety. Now it’s a real always-on host.

    Step 1 — A private AI brain that lives on the laptop

    Three stacked layers: chat UI, tools, agent runtime
    A private AI brain that lives on the laptop.

    The local engine is Ollama; the chat interface is open-webui (running in Docker). If you want the multi-agent version of this idea, I’ve also written up building a free AI agent army with Ollama and Claude. The only thing standing between me and a private, offline ChatGPT was one wrong setting — open-webui was pointed at a dead address. The fix was to aim it at the host:

    docker run -d --name open-webui --restart always -p 3000:8080 
      -v open-webui:/app/backend/data 
      -e OLLAMA_BASE_URL=http://host.docker.internal:11434 
      ghcr.io/open-webui/open-webui:main

    The proof: a 3-billion-parameter model (Llama 3.2) introduced itself in about 10 seconds at ~12 tokens/second — on the CPU, no NPU, no discrete GPU. Fast enough for real Q&A, drafting, and summaries. Seven models sit ready on disk, and the whole thing is reachable from my phone over a private network.

    Everything here runs offline. For anything I don’t want leaving the machine, that’s the entire point.

    Step 2 — Voice that never leaves the machine

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    Voice that never leaves the machine.

    A local Whisper speech-to-text container (OpenAI-compatible API) became a push-to-talk dictation tool: hold a key, talk, release, and the text drops into whatever app is focused. I verified the pipeline without even touching the mic — Windows text-to-speech generated a clip, the local Whisper transcribed it, and it round-tripped clean:

    Spoken: “Testing one two three. This is the private local transcription engine.”
    Whisper heard: “Testing 1-2-3. This is the private local transcription engine.”

    Windows has built-in dictation (Win+H) and Copilot voice too — but those ship your audio to the cloud. The local version does the same job, and your voice never leaves the laptop.

    Step 3 — Turn your phone into the control panel

    Using Tailscale (a private mesh network), every service on the laptop is reachable from my phone — without exposing anything to the public internet. I added a tiny web page (one small nginx container) as a mobile operator console: one tap to the local AI, automations, status, and finance dashboards. Pin it to the home screen and the laptop is in your pocket.

    The honest scoreboard vs. a Copilot+ PC

    Capability Copilot+ PC ($1,000+) This $400 laptop
    Private AI running on the device Limited (small NPU models) ✅ Full Ollama stack, 7 models
    An AI that operates the machine ❌ ✅ Runs commands, edits files, fixes things
    Private, offline voice dictation ❌ (cloud) ✅ Local Whisper
    Phone control panel ❌ ✅ Tailscale operator console
    Recall / Click to Do / Cocreator ✅ (needs the NPU) ❌
    Screenshots everything you do ⚠️ Recall does, by design ✅ No — nothing is recorded

    I’m being fair: the NPU-only features are genuinely off the table on cheap hardware. But for operating your computer — and for privacy — the architecture beats the chip.

    Why this matters more than it looks

    The quiet headline isn’t “I saved money.” It’s where the data lives. Microsoft’s flagship AI-PC feature, Recall, works by screenshotting everything you do. This build does the opposite: the sensitive payload stays on your machine, and the cloud is used only for the heavy thinking that doesn’t need your private files.

    That’s not just a hobbyist’s preference. It’s the exact requirement for anyone in a regulated field — healthcare, legal, finance — who can’t send client data to a third party but still wants real AI leverage. The cheap laptop isn’t the story. The architecture is.

    Frequently asked questions

    Do I need a Copilot+ PC or an NPU to run local AI?

    No. Any laptop with around 16 GB of RAM and a modern CPU can run small local models. An NPU accelerates certain Windows features but is not required for Ollama or local chat.

    Is local AI actually private?

    Yes. With Ollama, the model runs on your own machine and works with no internet connection — nothing is sent to a cloud service.

    What is the difference between Ollama and open-webui?

    Ollama is the engine that runs the models. open-webui is the friendly chat interface that sits in front of it.

    How fast is a local model on a budget laptop?

    On a CPU-only AMD Ryzen 5 with 16 GB of RAM, a 3-billion-parameter model answered at roughly 12 tokens per second — fine for quick questions, drafting, and summaries. Larger models run slower.

    Can I use it from my phone?

    Yes. Over a private Tailscale network you can reach your laptop’s AI and tools from your phone without exposing anything to the public internet.

    Is this better than a Copilot+ PC?

    For operating your machine and for privacy, this setup does more. For NPU-specific Windows features like Recall and Click to Do, a Copilot+ PC is required.

    Want this on your machine?

    Tygart Media builds privacy-first, local-AI operator setups — especially for teams in regulated industries that need real AI leverage without sending data to the cloud. Reach out and we’ll scope it to your hardware.

    >Part of the complete guide: Your Laptop Is Already an AI PC

  • Claude Code vs Cursor in 2026: An Honest Comparison for Developers Who Ship

    Claude Code vs Cursor in 2026: An Honest Comparison for Developers Who Ship

    The conversation about Claude Code vs Cursor has collapsed into lazy takes: Claude Code is smarter, Cursor is friendlier, buy both. That framing is not wrong, but it isn’t useful. If you’re deciding where to put your coding tool budget in 2026, you need to know where each tool wins and loses – with specifics, not vibes.

    Here’s what a year of both tools in production actually looks like.

    The Fundamental Architecture Gap

    Side-by-side cards defining what Claude Code is and is not
    The fundamental architecture gap.

    Claude Code is a terminal-native CLI agent. You run it with claude in your shell, point it at a codebase, give it a task, and walk away. It has no GUI. It doesn’t autocomplete as you type. What it has is the ability to autonomously execute multi-step tasks – read files, write code, run tests, iterate on failures – without you babysitting it.

    Cursor is an IDE built on VS Code. It has tab autocomplete, an inline chat panel, Agent mode for longer tasks, and a polished visual interface that feels like VS Code with a superpower grafted on. If you already live in VS Code, Cursor’s learning curve is close to zero.

    These are genuinely different tools. The “which one wins” question should really be “which one wins for what.”

    Where Claude Code Wins: Long Autonomous Runs

    Five stacked panels of daily Claude Code command habits
    Where Claude Code wins — long autonomous runs.

    The biggest measurable advantage Claude Code has right now is context. Running on Claude Opus 4.6 or 4.7, Claude Code natively supports a 1 million token context window – and that’s a first-class, supported number with no per-token surcharge for long context on the API.

    Cursor’s advertised context is lower, and it draws from multiple model backends depending on which you select. On a large monorepo task – think refactoring an auth system across 40 files – the difference between context limits is the difference between Claude Code holding the whole codebase in view and the alternative having to page through it.

    Claude Opus 4.6 scores 80.84% on SWE-bench Verified, per Anthropic’s published system card. Opus 4.7 improved on that, particularly on the hardest problems in the benchmark set, and on Rakuten-SWE-Bench (a production-task evaluation, not just GitHub issues) it resolves 3x more tasks than Opus 4.6. That is a meaningful gap.

    The autonomous-run workflow looks like this in practice:

    claude "Refactor the payment module to use the new Stripe SDK, update all tests, and make sure existing integration tests still pass"

    Claude Code will read the relevant files, identify the Stripe version mismatch, write the new implementation, run your test suite, and iterate if something fails – often without a single follow-up prompt. That same task in Cursor’s Agent mode typically requires you to approve each file write and re-prompt when the agent stalls on an error.

    Where Cursor Wins: Daily Developer Experience

    Cursor’s tab autocomplete is genuinely good. It’s not a feature Claude Code has at all – Claude Code is not an IDE and doesn’t inject suggestions while you type. If your daily workflow is: open file, write code, open file, write code, Cursor is the better tool for that rhythm.

    Cursor’s @codebase reference and file mention system is also excellent for interactive exploration. You can ask “why does this function fail on null input?” while looking at the code, and Cursor’s inline context makes that conversation fast. Claude Code can answer the same question, but you’re doing it in a terminal with no visual reference.

    For teams on an existing GitHub workflow, GitHub Copilot’s deep integration with PRs, issues, and Actions is hard to match. If your team is standardized on GitHub and your security team needs IP indemnity coverage, Copilot is the defensible enterprise choice – Claude Code and Cursor both require more procurement work.

    The Pricing Reality

    Plan Monthly Cost
    Claude Code via Claude Pro $20/month
    Claude Code via Max 5x $100/month
    Claude Code via Max 20x $200/month
    Cursor Pro $20/month
    GitHub Copilot Individual $10/month

    The entry point is the same for Claude Code (via Claude Pro) and Cursor. At that tier, Claude Code’s usage limits are more restricted. The Max 5x plan at /month is where Claude Code becomes a full autonomous-agent platform – higher rate limits, Opus access, and Claude Code usage limits that are double the Pro tier.

    For individual developers doing heavy autonomous runs, the Max 5x plan at competes directly with a Cursor Pro subscription plus meaningful API spend. For teams, the calculus shifts: Cursor’s team plan pricing is lower per seat than a premium Claude Code subscription, which matters when you’re buying for 20 developers.

    The Honest Call

    Three cards for fast volume, daily workhorse, and deep flagship Claude seats
    The honest call.

    Claude Code wins on: autonomous multi-step tasks, large codebase refactors, long-running agents, raw SWE-bench performance, and 1M token context on complex jobs.

    Cursor wins on: daily IDE experience, tab autocomplete, interactive inline chat, onboarding speed for VS Code users, and team-tier pricing.

    The recommendation most senior developers are landing on in 2026 is two tools: Cursor open in the background for interactive work, Claude Code for the tasks you used to put in a Jira ticket and wait two days for. If you can only buy one and you mostly write code file-by-file, get Cursor. If your bottleneck is “I need to refactor three services and I don’t have three days,” Claude Code is the one that changes your output.

    The Max 5x plan makes that bet financially coherent for a senior developer. The Pro tier is a reasonable way to find out if autonomous coding is a workflow you actually use.

    Frequently Asked Questions

    Is Claude Code better than Cursor in 2026?

    It depends on your workflow. Claude Code is a terminal-native CLI agent best for large codebase refactors, multi-file operations, and agentic tasks run from the command line. Cursor is an IDE-first editor with inline completions and a chat sidebar — better for continuous editing with visual feedback. Most developers who ship code daily use both rather than choosing.

    What is the difference between Claude Code and Cursor?

    Claude Code is a CLI tool you run with the ‘claude’ command in your terminal — it acts as an autonomous agent that can read, edit, and run files across a codebase. Cursor is a VS Code fork with AI completions and chat built into the editor interface. Claude Code suits agentic automation; Cursor suits interactive editing.

    Can I use Claude Code and Cursor at the same time?

    Yes. Many developers run Claude Code from the terminal for large refactors or test-writing sessions while keeping Cursor open for active editing. They complement each other: Claude Code for autonomous multi-step tasks, Cursor for line-by-line interactive work.

    How much does Claude Code cost in 2026?

    Claude Code usage is billed through your Anthropic API account against whichever Claude model you select. Claude Opus 4.8 (legacy — still listed) runs $5 per million input tokens and $25 per million output tokens. Claude Sonnet 4.6 (legacy — still listed) runs $3/$15 per million tokens. Claude Haiku 4.5 runs $1/$5 per million tokens. Cursor’s plans start around $20/month for Pro.

    Lineup currency (Sept 2026): Current API list (Sept 2026, verified): Sonnet 5 $2/$10, Opus 5.5 $4/$20, Haiku 4.5 $1/$5, Fable 5.1 $10/$50. Legacy (still listed on Anthropic’s card): Opus 4.8 $5/$25, Sonnet 4.6 $3/$15.

    Does Cursor use Claude under the hood?

    Cursor supports multiple underlying models including Claude (Anthropic), GPT-4 (OpenAI), and others. You can select which model Cursor routes to in its settings. Claude Code, by contrast, is a dedicated Anthropic CLI tool that only runs on Anthropic’s Claude models.

    What is Claude Code best used for?

    Claude Code excels at large-scale codebase operations: refactoring across multiple files, writing comprehensive test suites, navigating unfamiliar codebases, and running agentic tasks that chain multiple steps. It is less suited for inline autocomplete as you type — Cursor is better at that.

  • Claude Code Limits: Permanent +25% Weekly After the Sep 13 Promo (September 2026)

    Claude Code Limits: Permanent +25% Weekly After the Sep 13 Promo (September 2026)

    Last verified: October 1, 2026 (Pacific). Sources: Anthropic Help Center — Claude Code May–August 2026 weekly limits promotion (updated; permanent +25% now official) and Fable-on-plan article. Exact token counts are not published — check Settings → Usage or /usage in the CLI.

    Direct answer: Claude Code has two meters. A rolling 5-hour session limit that the May 2026 doubling made permanent, and a weekly usage limit. The temporary +50% weekly promotion ended September 13, 2026 at 11:59 PM PT — do not claim +50% as live. Starting September 14, 2026, Anthropic Help Center states weekly limits in Claude Code are permanently 25% higher than the pre-promotion baseline for Pro, Max, Team, and seat-based Enterprise. That is lower than the promo week (1.5×) and higher than the old baseline (1.25×). The 5-hour window did not change. Fable 5 and Fable 5.1 are included only on Max, Team Premium, and seat-based Enterprise Premium, and they may use at most 50% of the weekly pool.

    The two clocks

    People treat “I hit my limit” as one event. It is two.

    • 5-hour session. Rolling window. Burns when the model is working, not when you are idle. Anthropic doubled this across paid plans on May 6, 2026 and removed the old peak-hour throttle for Pro and Max. Neither the +50% weekly promo nor the permanent +25% weekly change raised or lowered this clock.
    • Weekly bucket. Fixed reset time on your account (Settings → Usage). This is the one that ends a Friday on Max after a Fable week. The May–September 2026 +50% promotion applied to Claude Code only — CLI, IDE, desktop, and web Code — not to Claude chat or Cowork. That temporary bump is over. What remains: the permanent +25% over the pre-promo weekly baseline (Help Center).

    Eligible for the promo and the permanent +25%: Pro, Max, Team, and legacy seat-based Enterprise. Not eligible: Free and consumption-based Enterprise.

    The September 13–14 change

    Official Help Center timeline:

    • May 13 – Sep 13, 2026 11:59 PM PT: Claude Code weekly limits were 50% higher than the pre-promotion baseline. 5-hour limits were not affected.
    • Starting Sep 14, 2026: weekly limits in Claude Code are permanently 25% higher than they were before the promotion for Pro, Max, Team, and seat-based Enterprise. Plan price unchanged.
    • 5-hour limits stay at the May doubled level.

    Cite: support.claude.com/en/articles/15910845.

    Compared to last week’s promo, you have less weekly headroom than 1.5×. Compared to the old baseline, you have more: 1.25×. Exact quotas are still unpublished — read your live number in Settings → Usage.

    Who gets Fable 5.1 on the subscription

    Official: Claude Fable models on your plan. Fable 5 and Fable 5.1 follow the same plan rules.

    Plan Fable 5 / 5.1 on the subscription
    Free Not included
    Pro ($20) Not in plan limits. Usage credits from the first Fable token.
    Team Standard Same as Pro: credits, not included.
    Max 5x / Max 20x Included, capped at 50% of weekly limits. Same pool as Sonnet and Opus.
    Team Premium / Enterprise Premium seats Same 50% included cap as Max.
    Enterprise Standard seats Only if the org enables usage credits.
    API / usage-based Enterprise List rates. See Fable pricing.

    The July 2026 one-time $100 credit for Pro / Team Standard applied to the Fable 5 plan change. Help Center says there is no matching credit for Fable 5.1.

    Practical read: Pro can still open Fable. It just bills. Max can spend half the week on Fable before the included cap trips, then it is credits or switch to Opus 5 / Sonnet 5.5. Fable burns the shared weekly bar faster than Sonnet — plan against the permanent +25% weekly bar, not the old promo week.

    What still burns quota

    • Long agent loops and multi-agent fan-out (each worker keeps its own context).
    • Dumping a whole repo when one file would do.
    • MCP tool output that stays in context for the rest of the session.
    • Leaving ANTHROPIC_API_KEY set so the CLI bills API rates and ignores the subscription.

    What to do now

    • If you are on Pro and need Fable all week, budget credits or move the hard jobs to Max. The subscription does not include Fable on Pro.
    • If you are on Max, treat weekly headroom as permanent +25% over the old baseline — not the temporary +50% promo week. Route cheap loops to Sonnet 5.5; save Fable for the jobs that need it. Check Settings → Usage / /usage for your real number.
    • Do not upgrade from Pro to Max only because the 5-hour window feels tight on Friday. Check which clock you hit. Session vs week is a different purchase.

    >Part of the complete guide: Claude Code

  • Claude Code MCP Scopes: Mastering the –scope Flag

    Claude Code MCP Scopes: Mastering the –scope Flag

    Everyone teaches you how to add an MCP server to Claude Code. Almost nobody teaches you where to add it — and that one decision, the scope flag, is the difference between a clean team setup and three engineers debugging why the same server works on one machine and not another. I’ve watched it happen. The fix is always the same: someone added a server at the wrong scope.

    If you run claude mcp add without thinking about scope, Claude Code makes the choice for you. It defaults to local. That’s fine for a throwaway experiment and wrong for almost everything else.

    The three scopes, and what each one actually controls

    Flow from app/IDE through MCP to servers and data APIs
    The three scopes, and what each one actually controls.

    Claude Code stores MCP server configurations in three places, and the --scope flag decides which one you’re writing to.

    Local scope (the default) writes the server config into your personal settings, keyed to the current project path, inside ~/.claude.json. Nobody else sees it. It doesn’t get committed. Open the same repo on your laptop at home and the server isn’t there. This is the scope you want for a one-off — a database you’re poking at this afternoon, a server you’re still deciding whether to keep.

    Project scope writes to a .mcp.json file at the root of the repository. You commit that file to git. Everyone who clones the repo gets the same servers, configured the same way. This is the scope that makes MCP a team decision instead of a personal one — and it’s the one most people skip because the default never points them at it.

    User scope writes to your global config so the server is available in every project you open, regardless of which repo you’re in. This is for the handful of servers you genuinely use everywhere — a documentation search server, a personal notes tool — not for anything project-specific.

    The mental model I use: local is “me, here, now.” Project is “anyone on this repo.” User is “me, everywhere.” If you can articulate which of those three sentences describes the server, you know the flag.

    The command, written three ways

    Five stacked panels of daily Claude Code command habits
    The command, written three ways.

    Same server, three scopes. The only thing that changes is the flag.

    # Local — default, personal, not committed
    claude mcp add --transport stdio my-db -- npx -y @some/db-mcp-server
    
    # Project — shared via .mcp.json, commit to git
    claude mcp add --scope project --transport stdio my-db -- npx -y @some/db-mcp-server
    
    # User — available in every project you open
    claude mcp add --scope user --transport stdio my-db -- npx -y @some/db-mcp-server

    Verify what’s connected and where it came from with claude mcp list. If a teammate reports a server “isn’t working” and yours is fine, this is the first command to run on both machines — the discrepancy is almost always a scope mismatch, not a broken server.

    The .mcp.json pattern that actually pays off

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    The .mcp.json pattern that actually pays off.

    Here’s the workflow that turns this from trivia into leverage. When you onboard a repo that the whole team uses, you decide once which MCP servers belong to that codebase — the Postgres server pointed at the dev database, the issue tracker, whatever the repo’s daily work requires — and you add them all at project scope. The resulting .mcp.json looks like this:

    {
      "mcpServers": {
        "postgres": {
          "command": "npx",
          "args": ["-y", "@some/postgres-mcp-server", "postgresql://localhost/devdb"]
        },
        "linear": {
          "type": "http",
          "url": "https://mcp.linear.app/mcp"
        }
      }
    }

    Commit it. Now a new hire clones the repo, opens Claude Code, and the agent already knows how to query the dev database and read tickets — no setup doc, no Slack thread asking “wait, how do I connect the database again.” The repo carries its own integration surface.

    One safety detail worth knowing: when Claude Code encounters project-scoped servers from a .mcp.json it didn’t write, it asks you to approve them before they run. That prompt exists because a committed config file is, technically, code other people can put on your machine. Read what you’re approving — the same way you’d read a package.json script before running it.

    Where this bites people

    Three failure modes I see repeatedly. First: adding a server at local scope, then wondering why it vanished on a different machine — local is path-and-machine specific, that’s the design. Second: putting a secret directly into .mcp.json and committing it to a public repo. Don’t. Reference an environment variable in the config and keep the actual token out of git. Third: piling everything into user scope so every project loads servers it doesn’t need, which bloats the context the agent has to reason over and slows routing when you have many tools connected.

    The cost angle, since it’s a fair question: scoping itself costs nothing. But every connected MCP server adds its tool definitions to the model’s context on each turn. With Sonnet 4.6 as the workhorse model, a lean per-project tool set is faster and cheaper than a kitchen-sink user-scope config you never pruned. Scope discipline is, indirectly, token discipline.

    The rule that replaces all of this

    Before you run claude mcp add, finish this sentence: “This server should be available to ___.” If the answer is “just me, just here” — local. If it’s “anyone working in this repo” — project, commit the file. If it’s “me, in everything I do” — user. The flag follows from the sentence. Get that habit, and the entire class of “works on my machine” MCP bugs disappears from your team’s life.

  • Claude Code vs Cursor: Token Efficiency & Agent Teams

    Claude Code vs Cursor: Token Efficiency & Agent Teams

    I’ve been running both Claude Code and Cursor on the same codebases for the last eight months. Not as a reviewer — as someone who has to actually ship features in both tools and watch the credit meter tick. Here is what the comparison actually looks like in May 2026, after Cursor’s credit overhaul, after Claude Opus 4.7, and after Claude Code’s agent teams went GA.

    The Real Pricing Picture

    Workshop fuel gauge and metal tokens pouring into an API hopper, metaphor for pay-per-token pricing
    The real pricing picture — stale-proof.

    The headline subscription numbers are nearly identical: Claude Pro at $20/month, Cursor Pro at $20/month. That’s where the similarity ends.

    Cursor’s Pro tier in 2026 ships with unlimited “Auto” mode requests plus a $20 credit pool for premium models. Pro+ is $60/month with roughly 3x credits and background agents. Ultra is $200/month at 20x usage. Hobby is still free with limited requests. Teams is $40/user/month.

    Claude Code on the Pro plan gets you Sonnet-tier usage with quota limits. Max at $100/month unlocks Opus access and 5x the usage envelope. The team plan for Claude Code is where the real spread shows: Anthropic’s team pricing on Claude Code lands materially higher than Cursor Teams for a comparable seat count. If you’re a 10-person team buying the most generous tier of each, you’re looking at roughly 3x more for Claude Code.

    For solo developers, the cost is a wash at the entry tier. The decision is not about money — it’s about how each tool burns tokens.

    Token Efficiency Is the Hidden Variable

    This is the number I wish I had known a year ago: independent benchmarking through 2026 has Claude Code using roughly 5.5x fewer tokens than Cursor on identical tasks. Not 5.5% — five and a half times fewer.

    The why matters. Cursor’s agent loop tends to re-read files, re-include context, and verify intermediate steps by stuffing prior turns back into the prompt. Claude Code’s CLI architecture leans on a tighter context budget by default, and on Opus 4.7 the model itself is doing more work per token. When you’re paying by credit (Cursor) and your power-user-hours start adding up, that ratio is the difference between a $60 month and a $200 month.

    The honest counterpoint: Cursor’s median completion time on simple, single-file edits is roughly 12% faster than Claude Code. If you live in the find-and-fix-a-typo loop, Cursor’s IDE integration genuinely wins.

    Where Claude Code Wins

    Side-by-side cards defining what Claude Code is and is not
    Where Claude Code wins.

    The 1M token context window is now generally available on Claude Opus 4.6, Opus 4.7, and Sonnet 4.6, at standard per-token pricing with no long-context surcharge. A 900,000-token request costs the same per-token rate as a 9,000-token one. For codebases that need to be understood holistically — monorepos, large migrations, anything where “ctrl-F across 200 files” is part of the problem — this is the single most consequential capability difference in 2026.

    Agent teams went past experimental in 2026 with Claude Code v2.1.32 and the CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 flag. The team-lead pattern — one Claude session coordinating teammates who can message each other, share a task list with dependencies, and lock files — is a genuinely different primitive than Cursor’s background agents. The cost is real: agent teams use approximately 7x the tokens of a single session in plan mode. The benefit is also real: the work that previously needed a human program manager now runs unattended.

    On full-feature implementation tasks — the kind where a benchmark measures end-to-end PR shipment, not single edits — Claude Code was roughly 18% faster on median wall-clock time. Opus 4.7 specifically lifted resolution on a 93-task coding benchmark by 13% over Opus 4.6, including four tasks that neither Opus 4.6 nor Sonnet 4.6 could solve.

    Where Cursor Wins

    Five stacked panels of daily Claude Code command habits
    Where Cursor wins.

    The editor. This is not a small thing. Cursor is still a VS Code fork that evolved into an agent workbench. The integrated diff view, the multi-file edit preview, the in-line ghost text completions, the model picker in the corner — none of that exists in Claude Code, which lives in a terminal pane. If you have a strong opinion about your IDE and you want AI features welded inside it, Cursor is the answer.

    Cloud agents on Cursor Pro and above run AI tasks in isolated cloud VMs with no access to your local machine. The use case — fire off a refactor and walk away from your laptop — is well-served. The catch: background agents always use MAX mode, which adds a 20% surcharge on credit cost, and a single agent run on a 50,000-line codebase can consume around 22.5% of a Pro plan’s monthly credits. One bad day of agent runs eats your month.

    Model variety is also a Cursor advantage. You can route a task to a non-Anthropic model when the situation calls for it. Claude Code is Claude all the way down.

    What I Actually Run

    Both. For $40/month at the Pro tier on each, I get the most powerful AI coding setup available in 2026. Claude Code handles the long-context architectural work, the cross-cutting refactors, the agent-team orchestration where one Claude is doing program management and three teammates are touching different services. Cursor handles the IDE work — the small-bore edits, the in-line completions, the moments where I want to see a diff hover above the line I just changed.

    If forced to pick one, the answer depends on the work. Heavy backend, large codebases, multi-agent workflows: Claude Code. UI-heavy, single-file iteration, “I just want my editor to be smarter”: Cursor.

    The Honest Limitation

    Claude Code on a team plan is genuinely expensive at scale. A 10-person team running Claude Code at the team-equivalent tier is roughly 3x the Cursor Teams equivalent. If you’re cost-sensitive at headcount, that math may decide the question regardless of capability. The token-efficiency advantage helps Claude Code claw back some of that on per-task economics, but the subscription line item is the line item.

    Lineup currency (Sept 2026, verified): Sonnet 5 ($2/$10), Opus 5.5 ($4/$20), Haiku 4.5 ($1/$5), Fable 5.1 ($10/$50). Legacy (still listed): Opus 4.8 ($5/$25), Sonnet 4.6 ($3/$15). Prior note (superseded): The other honest limitation: model versions move fast. As of May 26, 2026, the prior Anthropic lineup claim was Claude Opus 4.7 (flagship), Claude Sonnet 4.6 (workhorse), and Claude Haiku 4.5. Any comparison written more than a quarter ago is already partially wrong on the model column. Read pricing pages, not blog posts, when you’re committing budget.

    The Bottom Line

    Cursor wins on editor experience, model variety, and team subscription cost. Claude Code wins on token efficiency, context window economics, agent-team primitives, and Opus 4.7’s raw coding capability on hard tasks. If you’re optimizing for one tool, pick the one that matches the bulk of your work. If you can afford $40/month, run both — and pay attention to which one you actually open first in the morning. That’s your real answer.

    Start here: Claude Code vs Cursor: Which AI Coding Tool is Better? — the full head-to-head comparison.

  • Parallel Claude Code Sessions: The Worktree Workflow

    Parallel Claude Code Sessions: The Worktree Workflow

    There is a moment, usually around your third Claude Code session, when the fantasy of parallel agents collides with the reality of a single human attention span. You opened a second terminal because Claude was thinking and you had nothing to do. You opened a third because the second one was thinking too. Now there are three streams of edits happening across three branches, and the question is no longer “can I run parallel sessions” — it is “did I just spend the next forty minutes reviewing diffs I could have written myself in twenty.”

    Git worktrees plus claude --worktree make multi-session work physically safe. They do not make it economical. The pattern below is the one I have settled on after running everything from two-up to a foolish eight-up. The short version: two is the default, four is the ceiling, and the ceiling is set by review bandwidth, not by Claude.

    What worktrees actually fix

    Side-by-side cards defining what Claude Code is and is not
    What worktrees actually fix.

    A git worktree is a second working directory attached to the same repository — its own branch, its own files on disk, sharing history and remote with the main checkout. Without them, running two Claude Code sessions against one clone is asking for a merge conflict you will not see coming. One session edits src/auth.ts while the other is mid-refactor of the same file; the second write wins; your tests pass; the first session’s logic is gone.

    The claude --worktree my-feature flag creates the worktree for you under .claude/worktrees/, checks out a new branch, and scopes the entire session to that directory. Edits in one -w session cannot touch files in another. That is the entire safety guarantee, and it is the only one you need to run multiple sessions in good conscience.

    The catch nobody mentions in the launch posts: a worktree is a fresh checkout. Your .env, your .env.local, your node_modules, your virtualenv — none of it carries over. The first session in a new worktree spends ten minutes failing in confusing ways because the environment is empty.

    The fix is a .worktreeinclude file at the project root, gitignore-syntax. Files that match a pattern and are gitignored are copied into the new worktree at creation. Tracked files are never duplicated. A two-line .worktreeinclude with .env* and .env.local is usually enough to get past the first failure mode. Dependencies are a separate problem — most teams either symlink node_modules or run install fresh per worktree depending on how strict their lockfile discipline is.

    The two-session pattern

    Side-by-side when to use a script versus an agent
    The two-session pattern.

    This is the default and the one that pays its setup cost on the first week. The shape:

    • Foreground session. What you are actively working on. You read every diff. You answer questions. You /plan the multi-file changes.
    • Background session, separate worktree. A bounded task you can describe in one paragraph and verify in one diff. Documentation update, refactor of a single module, dependency bump and test run, generated-API-client rebuild. You start it, switch back to the foreground, and check on it when it finishes.

    The economics are clean. The background task would have cost you context-switching time anyway — opening it, loading the problem into your head, doing the work, putting it down. Instead you describe it once, let Claude run, and review one diff at the end. Two sessions, one human, real time saved.

    The discipline that makes this work: the background task is always something you would be comfortable letting a junior engineer commit without a meeting. If you would not, it is not a background task — it belongs in the foreground.

    The four-session ceiling

    Above two, the gains compress fast. Three is fine if the third session is something near-trivial — a script, a one-off data migration, a README pass. Four is the practical ceiling and only on days where the work decomposes that cleanly.

    The reason is review, not Claude. Each session produces a diff. Diffs are not free to read. A senior engineer in flow reads code at maybe two hundred lines per minute with comprehension; a five-hundred-line diff from a Claude session costs at least two minutes of focused attention, often five if the change is subtle. Four sessions producing four diffs in the same ten-minute window means twenty minutes of review queued up — and you cannot review them in parallel.

    The pattern that breaks first is the one where you stop reading the diffs carefully because there are too many of them. That is the failure mode worth naming. The point of running parallel sessions is to compress wall-clock time. The point is not to compress review time, because review time is the part that actually catches the bug.

    If you find yourself merging diffs you have only skimmed, you are running too many sessions. Drop back to two.

    When the pattern earns its keep

    Two scenarios where multi-session worktrees clearly beat the single-session default:

    The refactor-and-feature split. You are in the middle of building a feature. Halfway through you notice the underlying module needs a refactor before the feature can be finished cleanly. In the single-session model you stop the feature, do the refactor, and restart the feature with the refactored module in your head. In the worktree model you fork the refactor into its own worktree, keep the feature work going in the main worktree against the unrefactored code, and rebase the feature onto the refactor once it lands. You do not lose your place on the feature work.

    The long-tail cleanup pass. A list of twelve small chores nobody wants to do in series: dependency updates, doc fixes, lint cleanups, deprecated-API migrations. Worktree per chore, three at a time, Stop hooks running the test suite, you reviewing as each finishes. The single-session alternative is a forty-five-minute slog. The parallel version is fifteen minutes of dispatch and review.

    The scenario where it does not earn its keep: novel design work where the right answer requires you to hold the whole problem in your head. Splitting attention across two unfamiliar design problems means doing both of them worse than you would have done either of them alone.

    The setup that makes it usable

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    The setup that makes it usable.

    If you have not done this before, this is the order:

    First, write a .worktreeinclude with at minimum .env* and any other untracked config your project needs. Test it by running claude --worktree test-include and verifying your env loads. Delete the worktree with git worktree remove .claude/worktrees/test-include once verified.

    Second, add a WorktreeCreate hook if your project has any setup beyond env files — installing dependencies, running migrations, building a generated client. The hook fires when claude --worktree is invoked, before the session starts, so any setup you script runs against a clean checkout every time. The hook output prints the worktree path on stdout and Claude opens there.

    Third, establish a worktree naming convention before you have ten of them sitting around. feature/auth-rewrite, chore/dep-bump-react, fix/oauth-callback — anything that tells you in a year what the worktree was for. The default .claude/worktrees/ directory fills up faster than you expect.

    Fourth, set a personal ceiling. Mine is four. Yours might be three. The ceiling is whatever number of diffs you can review carefully in the time the sessions take to run. Write that number down somewhere you will see it when you are about to open a fifth terminal.

    What this pattern is not

    It is not parallelization in the engineering sense. The sessions are not coordinating. They are independent. Tasks with real dependencies — “refactor module A, then build feature B against it” — belong in one session, sequenced, with a /plan step in the middle. Splitting them across worktrees just means you spend extra time rebasing.

    It is also not a productivity hack in the autonomous-agent sense. Claude Code’s subagents and skills are the right tools when you want the same session to delegate work to context-isolated children. Worktrees are for when you want to run independent sessions in parallel because the tasks are independent and you can review the outputs separately. Different layer, different problem.

    The worktree pattern works because git worktrees were already the right primitive for parallel feature work before Claude Code existed. claude --worktree is the convenience flag that makes the primitive cheap. The discipline — two by default, four at the ceiling, never more diffs than you will actually read — is the part that turns convenience into useful workflow.

  • Claude Code Server-Managed Settings: Admin Console Setup

    Claude Code Server-Managed Settings: Admin Console Setup

    Last week I argued that if you have more than a handful of engineers on Claude Code, repo-level .claude/settings.json is not enough — you need managed-settings.json deployed through MDM. That is still true. What changed in 2026 is that you no longer need an MDM team to roll it out.

    Claude Code now supports server-managed settings: a remote configuration tier pushed from the Claude.ai admin console, with no file on disk and no MDM involvement. If you are on the Team plan running Claude Code 2.1.38+ or the Enterprise plan running 2.1.30+, this is available to you today, and most platform teams I talk to are still treating MDM-deployed managed-settings.json as the only option.

    It is not. And the precedence rules matter.

    The New Top of the Settings Hierarchy

    Five-step path: account, API keys, billing, usage, workspaces
    New top of the settings hierarchy.

    Claude Code’s settings stack already had a clear order — repo > user > project > local — with managed settings sitting on top of all of them as the unoverridable tier. Server-managed settings now sit at the same top tier alongside MDM and the on-disk managed-settings.json file. Within that managed tier, the documented precedence is:

    1. Server-managed settings (admin console push)
    2. MDM / OS-level policies (Jamf, Kandji, Group Policy, Intune)
    3. managed-settings.json on disk (the file we deployed last week)
    4. HKCU registry (Windows)

    Server-managed wins. If you push a policy from the admin console that conflicts with a fleet managed-settings.json deployed by MDM, the server policy applies. That is the entire point.

    What This Actually Replaces

    For organizations without a mature endpoint management pipeline — which is most companies smaller than a couple hundred engineers — the old path looked like this: get IT to package a JSON file, push it through Jamf or Group Policy, verify on a pilot machine, then deploy fleet-wide. Two-week ticket minimum.

    Server-managed settings collapse that to: log into the admin console, write the policy in the UI, save. Claude Code clients fetch the new policy at startup and re-poll hourly during active sessions. No reboot. No reinstall. No ticket.

    This is a real change in posture. The friction that kept smaller teams from deploying any managed policy at all just dropped to near zero.

    The Approval Gate Most Teams Will Hit

    Five security domains: identity, data, code governance, audit, agents
    The approval gate most teams will hit.

    Server-managed settings have one behavior MDM-deployed settings do not: certain categories require explicit user approval before they apply on a given machine. The current list per the docs:

    • Shell command settings (custom commands surfaced to the model)
    • Custom environment variables (anything injected into the model’s process env)
    • Hook configurations (pre/post-tool-use hooks)

    These three need the user to click through an approval prompt the first time the new policy hits their client. Deny rules in permissions.deny, the audit log path, telemetry settings, default model — those apply silently.

    The reasoning here is sound: a malicious admin (or a compromised admin account) could otherwise inject a hook that exfiltrates every prompt or a shell command that pipes diffs to an external endpoint. Approval gating those three categories means a developer at least sees the change before it takes effect. It also means your “push the new hook policy fleet-wide” plan has a manual confirmation step you cannot skip.

    If you need silent enforcement of hooks or shell commands, MDM-deployed managed-settings.json still does that without the prompt. Use the right tool for the right setting.

    What Belongs on the Server, What Belongs in MDM

    After running both for two weeks across a small fleet, the split that has held up:

    Push from the admin console:

    • permissions.deny rules that should be hot-updatable when a new exfil vector is discovered
    • Default model pinning (when you want to change it without re-deploying)
    • Telemetry and audit log endpoints
    • Anything you want to A/B across user groups (more on this in a second)

    Keep in MDM managed-settings.json:

    • Hook configurations you need to enforce silently
    • Shell command allowlists that must apply before first launch
    • Anything that needs to survive the user being signed out of their org account

    The reason for the second list is that server-managed settings only apply once the user authenticates with org credentials. A fresh laptop with a developer running claude before signing in gets no server policy. MDM-deployed settings apply from the first invocation.

    Group-Targeted Policies Are the Sleeper Feature

    Anthropic added user groups to the admin console earlier in 2026. Groups can be created manually or synced from an IdP via SCIM, and each group can be assigned a custom role plus its own spend limit. The piece most teams have not connected yet: server-managed settings respect group membership.

    This means you can push one permissions.deny policy to the “Security” group and a different one to the “Platform” group without writing two separate managed-settings.json files and pushing them through MDM with different scoping. Write two policies in the console, assign to groups, done. Group membership changes via SCIM propagate within the hour-long polling window.

    For a 200-engineer org that previously needed Jamf smart groups + MDM JSON variants to do the same thing, this is significant.

    Verification Workflow

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    Verification workflow for managed settings.

    The same verification workflow from the MDM-deployed setup still applies, with one addition:

    1. Push the policy in the admin console
    2. On a test machine, run claude config list — server-managed settings should appear flagged as such
    3. Attempt a denied action, confirm immediate block
    4. If hooks or shell commands are in the policy, walk through the approval prompt
    5. Sign the test user out, sign back in, confirm policy reapplies

    The sign-out test matters because that is where server-managed differs most from on-disk managed settings — the policy is bound to the org-authenticated session, not the machine.

    Model Versions for Org-Wide Pinning

    If you pin a default model via server-managed settings, the current strings are: claude-opus-4-7 (flagship), claude-sonnet-4-6 (workhorse), and claude-haiku-4-5-20251001 (fast). Verify against the live model list at docs.anthropic.com/en/docs/about-claude/models before deploying — model strings change frequently and pinning to a deprecated one will silently break agent runs.

    Where Server-Managed Settings Lose

    Three real limitations:

    1. No silent hook/shell-command enforcement. User approval is mandatory for those three categories.
    2. No effect before org auth. Pre-auth sessions ignore server policy entirely.
    3. No fine-grained rollback. Console changes apply globally within the hour. There is no canary group, no staged rollout percentage, no “apply to 10% of fleet for 24 hours” toggle. If you push a bad deny rule, every active session picks it up at next poll.

    Mitigate the third one by maintaining a single non-production test group that you deploy to first, wait 90 minutes, then promote the policy to broader groups. It is a manual canary, but it is the canary you have.

    The 20-Minute Rollout for a Team Already on Team Plan v2.1.38+

    1. Open the admin console at claude.ai → Settings → Claude Code policies
    2. Write a minimum-viable policy: deny curl, wget, rm -rf /, .env reads, credential files
    3. Assign to a single test group (one user)
    4. On that user’s machine, run claude config list — confirm the server policy appears
    5. Try three denied actions, confirm all blocked
    6. Expand assignment to one team
    7. Wait 24 hours, watch for tickets
    8. Roll org-wide

    The whole sequence takes longer than it runs because of the wait windows, not because of the work. The actual work is twenty minutes.

    Why This Article Exists

    The MDM-deployed managed-settings.json approach from last week is still the right answer for orgs that need silent, pre-auth policy enforcement. For everyone else — which is most teams adopting Claude Code in 2026 — server-managed settings are the easier path and most platform teams I talk to do not know they exist yet. Admin console push, no on-disk file, no MDM dependency, group-scoped via SCIM. If you are on a recent Team or Enterprise plan, this is the deployment posture you actually want.

    Sources

    • docs.anthropic.com/en/docs/about-claude/models (model version strings)
    • code.claude.com/docs/en/server-managed-settings (server-managed settings docs)
    • code.claude.com/docs/en/admin-setup (admin setup reference)
    • support.claude.com/en/articles/11845131-use-claude-code-with-your-team-or-enterprise-plan (Team/Enterprise Claude Code usage)
    • support.claude.com/en/articles/13799932-manage-groups-and-group-spend-limits-on-enterprise-plans (group management + spend limits)
    • support.claude.com/en/articles/13133195-set-up-jit-or-scim-provisioning (SCIM provisioning)
    • claude.com/product/claude-code/enterprise (Enterprise plan overview)
    • anthropic.com/news/claude-code-on-team-and-enterprise (admin controls launch)

    Related on Tygart Media: how to use Claude · Anthropic API key.

  • Claude Code Rollout: 35% Productivity Lift Case Study

    Claude Code Rollout: 35% Productivity Lift Case Study

    If you want to understand why some Claude Code rollouts compound and others quietly stall, stop looking at license telemetry and start looking at one artifact: the skill library. Every public 2026 case study with sustained productivity gains has the same shape — a committed skill kit, tight CLAUDE.md files, a handful of hooks, and a Friday retro cadence the team actually keeps. Teams that buy seats and skip the artifacts get install-only adoption and a dashboard that reads flat for a quarter.

    The 30-engineer case that landed at 35% productivity lift

    Side-by-side cards defining what Claude Code is and is not
    30-engineer case — productivity lift framing.

    The cleanest recent case study comes from a Digital Applied write-up published May 15, 2026 — an anonymized composite tracking a Series-B SaaS shop with thirty engineers across six squads on a Node/TypeScript monorepo. The team had Claude Code seats for the better part of a year before the engagement started. Roughly half the engineers used the CLI weekly. Zero shared skills, no committed project settings, no hooks, two squads with no project memory at all.

    The day-zero audit on a 50-point scorecard came in at 19/50. Ninety days later it hit 41/50 — a 22-point shift from late Stage 1 to mid-Stage 3. The headline number reported to leadership: a sustained 35% productivity lift, engagement-weighted, that held flat into month four.

    The shipped artifacts behind that number:

    • 22 shared skills, with authorship spread across 9 engineers
    • 11 wired hooks across three archetypes (notification, audit, gate)
    • 3 custom subagents — code-reviewer, ticket-triager, release-notes-writer
    • CLAUDE.md files pruned and held under 400 lines per repo

    The most-invoked skill was commit, accounting for roughly a third of all invocations by month four. That kind of skew is normal in a mature library and tells you which workflow is actually being changed by the rollout.

    Why CLAUDE.md hygiene predicts depth

    Five stacked panels of daily Claude Code command habits
    CLAUDE.md hygiene predicts depth.

    The single most actionable lesson from the case study is mechanical: cap CLAUDE.md at 400 lines and enforce it in PR review. Two squads in the engagement drifted past 800 lines in sprint two. Their skill-invocation rate ran roughly 40% lower than the four squads that held the line.

    The hypothesized mechanism, validated in two follow-up retros: bloated memory causes the model to skim the file rather than internalize it, which produces more generic responses, which makes engineers reach for the tool less often, which drops invocation rates further. The cycle is self-reinforcing in either direction. When the team ran a month-four prune that cut the average CLAUDE.md from 520 to 340 lines, skill-invocation rate rose 12% across the team in the following two weeks.

    The discipline: long-form content moves to .claude/docs/ as sub-docs with one-line summaries and links in the main file. The main file stays orientation-shaped — who the team is, what the repo does, where to look for the rest.

    The productivity panel mistake every team makes first

    Version one of this team’s productivity panel was wrong, and that wrongness taught the rollout more than any single milestone after it. The first panel tracked the metrics license telemetry already covered: total sessions opened per week, total tokens, average session length. It read flat for six weeks while the underlying capability of the team was visibly shifting in retros and PRs.

    Version two, rebuilt in week eight, weighted around engagement signals:

    • Skill invocations split by skill
    • Subagent runs per week
    • Time-to-first-meaningful-output for new contributors
    • Audit-score deltas from the quarterly 50-point scorecard
    • PR-to-merge time on Claude-Code-assisted PRs versus baseline

    By month four the panel showed roughly 410 skill invocations per week, 85 subagent runs per week, new-hire time-to-first-meaningful-output at -45% versus baseline, and PR-to-merge time -18% versus baseline. The 35% headline was an engagement-weighted composite of those signals, not a single measurement — and the team was careful never to frame it as “engineers ship 35% more code,” because that framing invites a debate the panel cannot win.

    How this case lines up with the rest of the 2026 cohort

    The Digital Applied 30-dev case is not an outlier. A companion case study from the same firm, dated May 13, 2026, covers a 100-developer engineering organization that sustained a 28% productivity lift with a 32-entry skill library over six months. That team ran Claude Code and Cursor side-by-side: Claude Code as the terminal/CLI surface for refactors, multi-file edits, codebase navigation, and review automation; Cursor as the in-editor surface for line-level completion and inline review.

    The pattern that replicates across both engagements is the cadence, not the contents. Three ninety-day sprints — install, leverage, governance — plus an explicit sustain phase that starts at day 90 with the same owner and the same Friday retro cadence as the active sprints. Treating days 91+ as a vague quarterly review is the most common reason adoption drifts back to install-only inside two quarters.

    What to actually do on Monday

    Desk with laptop, checklist notebook, and billing card ready before creating an Anthropic API key
    What to actually do on Monday.

    If you have Claude Code seats and want a rollout that compounds instead of stalls, the operational order matters more than the contents of your skill library:

    1. Run the day-zero audit and write down the score. The 50-point rubric Digital Applied published is a defensible starting point; any scorecard that distinguishes install from artifacts from governance will do. The number is what makes the case for the engagement internally.
    2. Name the rollout lead and carve 20-30% of their week. Less than that and the calendar slips. The role shape is enough seniority to enforce milestone discipline, enough engineering depth to write skills and hooks rather than just steward them, and enough calendar discipline to keep the cadence intact when product pushes back.
    3. Calendar the four phase-end retros and the month-four review before sprint one opens. Friday retros are thirty minutes per squad per week — the cheapest part of the rollout and the most often skipped. The friction they catch in week three compounds silently for the rest of the sprint if you don’t.
    4. Build the productivity panel deliberately badly in sprint two and rebuild it in sprint three. The version-two rebuild is structural, not incremental. Trying to ship the right panel on the first try usually delays the cadence rather than improving the signals.
    5. Cap CLAUDE.md at 400 lines and enforce it in PR. This is the single highest-ROI hygiene rule in the engagement and the one teams skip most often because completeness feels safer than discipline.

    The honest framing: a single-quarter Claude Code rollout takes you from Stage 1 to mid-Stage 3 on a defensible scorecard. Stage 4 — the optimized end-state with deeper subagent governance, a security cadence that catches drift, and a productivity panel that has been iterated against a full quarter of data — is a second-quarter project. The teams that get there are the ones whose sustain phase looks identical to the sprints that preceded it. The teams that drift are the ones whose Friday retro disappeared sometime around month two.

    Model versions referenced throughout this piece reflect Anthropic’s current lineup as of May 2026: claude-opus-4-7 (flagship), claude-sonnet-4-6 (workhorse), and claude-haiku-4-5-20251001 (fast). If you are reading this six weeks from now, check the model docs before you copy any string into a config.

    Related on Tygart Media: how to use Claude · Anthropic API key.

  • Install Claude Code on Windows: Commands, Setup & First Run (2026)

    Install Claude Code on Windows: Commands, Setup & First Run (2026)

    Quick answer: Open PowerShell and run irm https://claude.ai/install.ps1 | iex, then open a new terminal and run claude. No admin rights, no Node.js needed — Windows 10 1809+ or Windows Server 2019+. On Mac/Linux the equivalent is curl -fsSL https://claude.ai/install.sh | bash. You’ll need a Pro, Max, Team, Enterprise, or API account to sign in — the free Claude plan doesn’t include Claude Code.

    If you’ve spent time in the Claude Code subreddit or GitHub issues lately, you’ve seen the same Windows install problem cycle through every week: someone runs the install command, it prints “successfully installed,” and then claude --version returns “not recognized.” Then come the suggestions — switch to Git Bash, switch to WSL2, reinstall Node, blow away npm. Half of them are wrong for the current installer. This guide covers the install that actually works in 2026, plus what to do in your first session.

    What changed: the native installer is now the default

    Anthropic shipped a native installer that removed the Node.js dependency entirely, and as of 2026 it is the recommended path on every platform. The old npm install -g @anthropic-ai/claude-code route still works but is no longer the primary method Anthropic tests and updates.

    The native installer downloads a single binary, drops it in ~/.local/bin, registers it on your PATH, and auto-updates in the background. On Windows that means: no Node, no npm, no WSL2 unless you specifically want a Linux toolchain. PowerShell on Windows 10 or 11 (64-bit) is enough.

    The commands that actually work

    Open Windows PowerShell — not the x86 version, not Git Bash, not Command Prompt. The x86 entry runs as a 32-bit process and will fail on a 64-bit machine. Git Bash doesn’t support the TTY features Claude Code’s interactive CLI needs, so you’ll hit a “Raw mode is not supported” error before you finish authenticating.

    Then run:

    irm https://claude.ai/install.ps1 | iex

    irm is Invoke-RestMethod, iex is Invoke-Expression — the script handles the binary download, PATH update, and shell hooks. When it finishes, close the terminal and open a new PowerShell window. This is the step everyone skips: the PATH change applies to new shells only.

    In the new window:

    claude --version

    You should see a version string. Then run claude with no arguments from any project directory — the CLI opens your browser, asks you to sign in, and authorizes the local install. End to end: under five minutes on a clean machine.

    On macOS or Linux, the equivalent one-liner is:

    curl -fsSL https://claude.ai/install.sh | bash

    Prefer a package manager on Windows? winget install Anthropic.ClaudeCode works too, but winget installs don’t auto-update — run winget upgrade Anthropic.ClaudeCode periodically.

    No terminal? Use Claude Desktop’s Code tab

    If you’d rather skip the terminal entirely, Claude Desktop (macOS and Windows) includes Claude Code as a graphical Code tab — visual file diffs, a built-in preview panel, no command line required. Install the app, sign in with a paid account, click the Code tab, choose a project folder, and you’re in.

    Session type What it does Best for
    Local Runs on your machine, accesses your files directly Everyday development work
    Remote Runs on Anthropic’s cloud, keeps going if you close the app Long-running tasks, autonomous work
    SSH Connects to a remote machine over SSH Server or cloud VM development

    On Windows, Git must be installed for local sessions to work. The CLI and the Desktop Code tab share configuration files and can run simultaneously on the same project.

    You need a paid account — the free tier doesn’t include Claude Code

    This catches new users every week. The free Claude.ai plan gets you chat; it does not get you Claude Code. You need one of:

    • Pro — $20/month (or $17/month billed annually)
    • Max 5x — $100/month, or Max 20x — $200/month
    • Team Premium — $100/seat/month annual (minimum 2 seats, maximum 150). Note: Team Standard ($25/seat) does not include Claude Code
    • Enterprise, or API credits (billed per token)

    Pro and Max draw from the same usage pool as regular Claude chat. If you’re evaluating whether to upgrade, the Pro window will tell you within a week — you either hit the cap during real work or you don’t.

    First-run authentication: two options

    Option 1 — Claude subscription (Pro, Max, Team, Enterprise). Run claude, select “Login with Claude.ai,” and a browser window opens to authorize. Your subscription covers usage — no separate API billing.

    Option 2 — Anthropic API key. Set the key as an environment variable first:

    $env:ANTHROPIC_API_KEY = "sk-ant-..."  # PowerShell
    claude

    API usage is billed per token at standard rates. For heavy daily use, a Max subscription is usually more economical than API billing.

    The five errors you’ll hit, and what fixes them

    “claude is not recognized as the name of a cmdlet.” Your PATH wasn’t updated, or you didn’t open a new terminal. Close PowerShell and reopen. If it persists, add the install location to your user PATH:

    $currentPath = [Environment]::GetEnvironmentVariable('PATH', 'User')
    [Environment]::SetEnvironmentVariable('PATH', "$currentPath;$env:USERPROFILE\.local\bin", 'User')

    Then open a new terminal and run claude doctor for a full diagnostic.

    “Raw mode is not supported.” You’re in Git Bash. Switch to Windows PowerShell — Git Bash lacks the TTY interface the CLI needs.

    Microsoft Store popup interrupts installation. A “Get an app to open this ‘claude’ link” popup sometimes appears on Windows 11. Dismiss it and re-run the install command. If it persists, install Git for Windows first — it registers URL handlers that resolve the popup.

    Duplicate npm and native installs. If you installed via npm before and later ran the native installer, you have two binaries on PATH and version checks disagree. Remove the npm one: npm uninstall -g @anthropic-ai/claude-code, then verify with where.exe claude — only one path should come back.

    “Invalid code” during OAuth. The browser login generates a one-time code you paste back into the terminal. It expires fast — complete the browser flow and paste immediately; press Enter to retry if it lapses.

    Your first session: the commands that cover 90%

    Run claude from inside a real project directory — not an empty folder. Claude Code reads context from the surrounding repo (including CLAUDE.md if one exists); starting empty makes the first interaction feel useless.

    claude — starts the interactive session (REPL). Describe what you want: “add a rate limiter to the auth middleware.” Claude reads the files it needs, proposes changes, and asks approval before modifying anything.

    claude -p "prompt" — one-shot, non-interactive. Good for scripting and CI:

    claude -p "What are all the API endpoints in this codebase?"

    claude -c — resume your most recent conversation with full context. claude --model — override the model for a session. claude mcp add — connect external tools (MCP servers) like GitHub or web search:

    claude mcp add github -- npx -y @modelcontextprotocol/server-github

    Slash commands inside a session

    Command What it does
    /help Show all available commands
    /clear Reset context without leaving the session
    /compact Compress prior context to save tokens
    /cost Token usage and estimated cost for this session
    /model Switch the model mid-session
    /init Generate a CLAUDE.md with project context
    /review Multi-agent code review of the current branch

    CLAUDE.md — project-level context

    Drop a CLAUDE.md file in your project root and Claude Code reads it automatically at session start — architecture notes, test commands, deploy targets, house rules (“never modify migration files directly”). Generate a starter with /init.

    Permission modes

    By default Claude asks before running bash commands or modifying files. --dangerously-skip-permissions skips all confirmations — use only in isolated environments (Docker, CI), never on your primary machine. During a session you can also “Allow always” individual tools for the rest of that session.

    The setup isn’t the hard part

    Most Windows pain in the Claude Code ecosystem comes from following install guides written for the npm-era CLI, then layering WSL2-era troubleshooting on top. The current path is one PowerShell command, a new terminal, and a browser login. The next thing to figure out isn’t installation — it’s whether your Pro window survives a real week of work, and whether your team needs Premium seats. That math determines the actual cost of Claude Code on Windows, not whether the binary runs.

    FAQ

    Do I need Node.js to install Claude Code on Windows?
    No. The native installer ships a single binary with no Node.js dependency. The npm route still exists and needs Node.js 22+, but it’s no longer the recommended path.

    Does Claude Code work on the free Claude plan?
    No. Pro ($20/month) is the cheapest way in.

    Why does claude --version say “not recognized” right after installing?
    Your terminal still has the old PATH. Close and reopen the terminal first.

    Do I need Git for Windows?
    Optional but recommended. With it installed, Claude Code runs shell commands through Git Bash; without it, it falls back to PowerShell.

    Does Claude Code auto-update on Windows?
    Native installs auto-update in the background. Winget installs don’t — upgrade periodically.

    Does Claude Code work on Linux?
    The Desktop app doesn’t support Linux, but the CLI does — curl -fsSL https://claude.ai/install.sh | bash.

    What’s the difference between the Desktop Code tab and the CLI?
    The Code tab is graphical (visual diffs, preview panel, no terminal); the CLI runs in your terminal with the same core operations. They share config and can run simultaneously.

    Can Claude Code access the internet?
    Not by default. Its WebFetch tool fetches a specific URL you provide; for live search, add an MCP server like Brave Search.

    What does Claude Code do with my code?
    File contents needed for inference go to the Anthropic API. With an API key you can configure zero data retention; on a subscription, standard Anthropic retention applies.

    Last verified July 2026 against the official Claude Code setup docs. Related on Tygart Media: Claude pricing · Anthropic Console & API keys.