four ways to run claude, and where your skills actually live

A skill you wrote on your laptop works in the terminal, works in the desktop app, and then a cloud session reports it was not found. Nothing failed. The file sits in a folder the cloud never reads.

That mismatch is the whole story of working with Claude in 2026. One account, four front doors, and configuration that only follows you through some of them. This post maps all four surfaces, spells out the setup steps for each, and answers the question that trips most teams: where should your skills, instructions, and project knowledge actually live?

the short map

Two of the four run on your machine. Two run on Anthropic's cloud. And one of them, Claude Projects, barely talks to the other three.

• claude projects (claude.ai): a chat workspace with persistent instructions and a document knowledge base. cloud only. no code execution against your repos.
• claude code on the web (claude.ai/code): a coding agent that runs each task in a fresh cloud vm with your github repo cloned into it.
• claude code in the desktop app: the same coding agent with a gui, running locally on your files by default, with cloud and ssh sessions available from the same window.
• claude code in the terminal: the original surface. every feature ships here first, and it is the one you script and automate.

claude projects: the chat workspace

Projects live inside the claude.ai chat app. Each project bundles two persistent things: project instructions (a standing prompt that loads into every chat in that project) and project knowledge (documents, text, and code files Claude reads for context). On paid plans, large knowledge bases switch automatically into retrieval mode (RAG), which expands capacity up to roughly 10x when the content approaches the context limit.

Setup takes five minutes:

1. In claude.ai, open Projects in the sidebar and create a new project. The name is a label for you; the model never sees it.
2. Set project instructions: role, tone, standing rules, output format. This is the closest thing the chat product has to a system prompt you control.
3. Upload project knowledge: policies, product docs, price lists, style guides, exported data. Markdown and plain text use the least space; exported HTML costs roughly double for the same content.
4. Start chats inside the project. Every new chat loads the instructions and can pull from the knowledge base.

Two behaviors to know before you rely on it. First, chats inside a project do not share context with each other; if a conclusion from one chat matters, it goes into the knowledge base or it is gone. Second, on Team and Enterprise plans a project can be shared with view or edit permissions, which makes it the only surface here with a built-in shared knowledge base for people who never open a terminal.

What Projects cannot do: touch your filesystem, clone a repo, run your test suite, or open a pull request. It is for knowledge work. For a store team that means SOPs, supplier docs, policy Q&A, and drafting, and none of the engineering below.

claude code on the web: a fresh vm per task

Claude Code on the web is the fully hosted coding agent. Every session gets a fresh virtual machine running Ubuntu 24.04 with your GitHub repository cloned into it and common toolchains preinstalled: Python, Node, Ruby, PHP, Java, Go, Rust, Docker, PostgreSQL, Redis. You never get a shell. You write prompts, Claude runs every command, and you review the diffs.

Getting started:

1. Go to claude.ai/code and connect GitHub (or run /web-setup from an existing terminal install). Onboarding creates a Default cloud environment for you.
2. Pick a repo, describe the task, and start the session. Review changes in the diff view and push from there; sessions can also auto-fix pull requests when reviewers comment.
3. When a task outgrows the browser, pull the session down to your machine with --teleport, or push local work up with claude --cloud.

The environment is where the real configuration lives, and it has four knobs:

• network access: None, Trusted (a curated allowlist of package registries, GitHub, and cloud SDK domains), Full, or Custom with your own domain list.
• environment variables in plain .env format, copied into the vm once at session start.
• a setup script: bash, runs as root before Claude launches, must exit zero and finish in about five minutes.
• caching: after the setup script completes once, Anthropic snapshots the filesystem and reuses it, so later sessions start with your dependencies already installed. The snapshot rebuilds when you change the script or roughly every seven days.

Security is the strongest part of this surface. All GitHub traffic goes through a proxy that keeps your real credentials outside the vm, and git push only works against the session's own working branch. All other outbound traffic passes through a security proxy.

The honest limits, as of August 2026: it is still a research preview. There is no secrets store; anyone who can use an environment can read its variables, so real credentials do not belong there. Interactive auth like AWS SSO does not work. Resources cap out around 4 vCPUs, 16 GB of RAM, and 30 GB of disk. And the rule that decides most setups: only what is committed to the repo, plus skills enabled on your claude.ai account, exists in a cloud session. Your machine's ~/.claude folder might as well not exist.

the desktop app: local files, same engine

The desktop app puts the same Claude Code engine behind a gui, in the app's Code tab. By default it runs local sessions: your filesystem, your git checkout, your installed tools. The same window can also start cloud sessions (the vms described above) and ssh sessions on remote machines, which makes it the one surface that spans both worlds.

Setup:

1. Install Claude Desktop and sign in with your claude.ai account.
2. Open the Code tab and point a session at a folder or repo.
3. Pick a permission mode (plan first, accept edits, or ask each time) and work. You get visual diff review, a live app preview, pull request status, and parallel sessions side by side.

Because it runs locally, it reads the same configuration as the terminal: your user-level ~/.claude folder and each project's .claude directory, including skills, hooks, and MCP servers. Scheduled tasks created in the desktop app also run locally and load skills from those same folders. A short list of CLI-only flags and features is not exposed in the gui; the docs keep the current list.

the terminal: everything ships here first

The command-line install is the full-control surface: hooks, subagents, agent teams, headless mode for scripts and CI, sandboxing, fine-grained permission rules, and complete plugin management all live here.

Setup:

1. Install with npm install -g @anthropic-ai/claude-code, or use the native installer from the setup docs.
2. cd into a repo and run claude. Run /init in the session to generate a starting CLAUDE.md, the project memory file Claude reads at the start of every session.
3. Configuration layers, each level overriding the one before: your user ~/.claude, then the project's .claude directory, then local overrides — with organization-managed settings taking precedence over all of them. MCP servers install at local, project, or user scope; project scope writes a .mcp.json you can commit.

The terminal also bridges to everything else. claude --cloud sends a task to a web vm. --teleport pulls a cloud session down. Remote Control does the reverse of a cloud session: it connects the web and mobile apps to a session running on your own machine, with your files and your network.

skills: one file, three places to keep it

A skill is a folder with a SKILL.md file: YAML frontmatter that tells Claude when to use it, then the instructions themselves. Creating one takes a minute:

mkdir -p ~/.claude/skills/summarize-changes

---
description: Summarizes uncommitted changes and flags anything risky.
---

Summarize the diff in two or three bullets, then list any risks.

Where that folder lives decides everything about who can use it. There are three real homes, and they do not overlap cleanly:

The details that bite:

• Cloud sessions never read ~/.claude/skills on your machine. They load the skills enabled on your claude.ai account plus whatever is committed to the cloned repo's .claude/skills/. A scheduled routine that calls a personal skill will report it not found until you move the skill to one of those two homes.
• claude.ai uploads accept only the open Agent Skills spec frontmatter: name, description, license, compatibility, metadata, and allowed-tools. Anything else fails the upload with a hard error. Claude Code extensions like dynamic context injection, forked subagent execution, argument hints, and skill-scoped hooks work only in Claude Code.
• When names collide across levels, enterprise skills override personal, and personal overrides project.

the github option: skills as plugins

There is a fourth distribution path that turns GitHub into your skill server: plugins. A plugin marketplace is nothing more than a git repository with a manifest file listing plugins, and each plugin can bundle skills, agents, hooks, and MCP servers.

The working loop:

1. Put your skills in a repo and add a .claude-plugin/marketplace.json manifest (the marketplace docs cover the schema).
2. On any machine: /plugin marketplace add your-org/your-repo, then /plugin install skill-pack@your-repo.
3. For cloud sessions, declare the plugin in the repo's .claude/settings.json. Repo-declared plugins install automatically when a cloud session starts; plugins enabled only in your user settings do not transfer.

Marketplaces support version pinning, release channels, and dependencies, so a team can ship one vetted set of skills to every laptop and every cloud vm from a single repo.

where the four actually meet

There are exactly three junctions.

The git repo is the main one. A committed .claude/ directory behaves identically in the terminal, the desktop app, and cloud sessions: CLAUDE.md, settings and hooks, skills, agents, rules, .mcp.json servers, and declared plugins all travel with the clone. If you maintain one artifact carefully, make it this folder.

Your claude.ai account is the second. It carries authentication, the skills you upload or enable, and session portability: web to terminal, terminal to web, resume in the editor, drive your own machine from your phone through Remote Control.

Cloud environments are the third. One environment definition (network rules, variables, setup script) serves sessions started from the web, the CLI, the desktop app, mobile, Slack, and scheduled routines.

Projects meet almost none of this. Project knowledge and instructions never flow into a Claude Code session, and Claude Code configuration never flows into Projects. The two products share your account and the skills concept, and that is the full list.

what we'd set up

For a solo operator or a small team, the arrangement that survives contact with all four surfaces:

• Make the repo the source of truth. CLAUDE.md, project skills, hooks, and .mcp.json committed. Everything else is convenience.
• Treat ~/.claude as a scratch layer. Useful for personal experiments, invisible everywhere else. Anything that proves out gets promoted into a repo or a plugin.
• Keep a plugin marketplace repo on GitHub for skills shared across projects or people.
• Upload spec-compliant copies of the few skills you also want in chat, Cowork, and routines.
• Use Projects for the non-code side of the business: policies, supplier docs, store SOPs, tone-of-voice, shared with the people who need answers, none of whom need a terminal.

This split is a large part of the AI adoption work we do with commerce teams: deciding which tasks to hand to Claude, and making sure the setup lives where every surface can find it.

sources

• What are projects? and creating and managing projects, Claude Help Center
• Claude Code on the web and cloud environments
• Extend Claude with skills
• Claude Code on desktop
• Set up Claude Code, memory and CLAUDE.md, plugin marketplaces, Remote Control