So the app is just the window?

The tools I use, the shell, files and Python, run in a temporary Linux machine in Anthropic's cloud. I don't live in that machine; I reach into it. Each chat gets its own, and when I run python, pip install or write a file, it happens there, in /home/claude. You can't see into it, so anything meant for you comes back as a file or an artifact.

• Between turns, files and installed packages stay put.
• After a reply ends, anything left running in the background, like a dev server, is stopped within a few minutes.
• After a while idle, the whole machine is reclaimed and its files go with it.

Its network is locked down. From the shell it can reach package registries (npm, PyPI) and GitHub, and not much else, so curl to an arbitrary site usually fails. That is why web search and fetching pages are separate tools that run outside it.

Most of what feels like Claude doing things isn't in the machine at all. Connectors (Gmail, Notion, Figma), web search, artifacts and memory are calls from Anthropic's side, so they keep working after it's gone. Memory carries across chats; the machine never does.

Your Mac is separate. I reach its files only if this chat is linked to it through the Claude desktop app, and it isn't. A path like ~/Projects/portfolio means your machine, not mine. The container is a throwaway workbench; what lasts is artifacts, files I've sent, connectors and memory.

The harness and the interface are separate layers. Some products ship them in one package and some ship them apart.

• The model is a function that returns text and does nothing else. You send it messages and a list of tool definitions; it sends back text, or a structured request like "call bash with ls src/". It can't run anything and remembers nothing between calls.
• The [[harness]] is the loop that turns that function into an agent. It sends the request, gets a tool call⁴¹ back, runs the tool, sends the result, and repeats until the model says it is done. On top of the loop: the system prompt, which tools exist, permission prompts, compaction, CLAUDE.md, hooks. The agenticness lives here, not in the interface.
• The interface shows you the loop. It displays messages, takes your input, shows approve and deny buttons. It decides nothing.

Where your picture needs a fix: the harness is a binary on your computer only when it runs locally. Its environment is wherever it runs. The same Claude Code loop runs in the cloud workspace we just talked about, so its environment is /home/claude, not your Mac.

Why "CLI" confuses. The claude binary is the harness and a terminal interface bundled together. Typing claude opens a full-screen chat, so it is really a TUI, a text user interface. claude -p "fix the lint errors" is headless⁸⁵ mode: no interface, just the loop, with output on stdout so scripts and CI can drive it. That is the true CLI.

The Agent SDK is the harness without the terminal interface, as a library: query() in TypeScript or Python. It drives the same Claude Code engine and streams messages back as JSON, so the desktop app and this chat can build their own interfaces on that stream.

Model = brain in a jar, harness = the loop that gives it hands, interface = the window you watch through. Claude Code is the harness; the terminal, the desktop app and VS Code are windows onto it.

Mostly yes. A regular container¹⁴ is one or more ordinary processes with limits on what they can see and use. On Linux, docker run node starts an ordinary process, and the kernel²⁹ applies two features to it:

• [[namespace|Namespaces]] control what it sees: its own process list (it thinks it is PID 1), its own network, its own hostname, its own root file system, which is the unpacked image¹⁵.
• [[cgroup|cgroups]] control how much it uses: CPU, memory, the number of processes.

There is no separate kernel. From the host, ps aux lists the containerised node next to your other programs. "Container" is a set of rules on a process, not a separate machine. People also say it of the stopped version, which is just files, the image layers and config.

This chat's "container" isn't one. I ran ps in it. PID 1 is a program called process_api, and right below it is kthreadd, the kernel's own thread manager, which you only see when you have your own kernel. The kernel's version ends in -fc, which points to Firecracker, a MicroVM⁹¹. So this workspace is a tiny virtual machine with its own Linux kernel, isolated by hardware virtualisation.

• Container: a process on a shared kernel. Starts in milliseconds and costs almost nothing extra, but isolation depends on the kernel holding up.
• MicroVM (Firecracker): its own kernel on virtual hardware. Starts in about a second and isolates more strongly, which matters when strangers' code shares the same servers.
• Full VM: the same idea with a whole virtual PC, devices and BIOS. Heavier and slower.

A container is a process wearing blinkers (namespaces) and a budget (cgroups). A VM, micro or not, brings its own kernel. This chat's workspace is the second kind.

A subagent⁹³ is the same agent loop run again with a fresh, empty context. The main agent starts it with a tool call and gets back only its final answer.

The problem it solves is that the context window⁶⁰ fills up. Each pass of the loop sends the whole conversation again, every file read and every search result included. Sweep 40 files to find where auth happens, and those dumps take up room for the rest of the session, costing tokens and burying what matters.

Mechanically, the harness gives the main agent a tool called Agent (it used to be Task). Calling it looks like any other tool call, with a type such as Explore and a brief: "Find where session tokens are validated. Report file paths and line numbers." The harness starts a second loop with a new message list holding only the subagent's own system prompt and that brief. It reads and searches for as many turns as it needs, and when it finishes, only its last message goes back as the tool result. The 40 file dumps stay in its context and are thrown away.

What it is not. Not a new container, and usually not a separate process: it is a separate conversation, a message array, run by the same harness, seeing the same files and shell. That is why Claude Code's Agent tool has isolation: "worktree", which gives a subagent its own copy of the repository (worktree⁵⁸) when you don't want it editing files the main agent is working on.

Configurable. In Claude Code you define one as a Markdown file in .claude/agents/, with name, description, tools and model at the top and a system prompt below. A reviewer given only Read, Grep, Bash can't edit files, and can run on a cheaper model. The main agent reads the description to decide when to use it, as it does for any tool.

• Clean context: keep the conclusion, drop the evidence.
• Parallel work: several at once, one per package in a monorepo, say.
• Specialisation: a narrow prompt and tool set.
• Fresh eyes: a reviewer that never saw the main agent's reasoning isn't biased by it.

The cost. The subagent knows only the brief, and the main agent sees only the summary, so detail is lost both ways, and several at once burn tokens fast. A vague brief gets a confident, wrong report. A subagent is a function call where the function is another agent loop.

What decides what is possible isn't which app you open. It is where the harness runs, because that machine is the one whose files it can see.

One correction to your reasoning. The web version can't see your laptop's files, but the browser's sandbox isn't why. In Claude Code on the web the harness doesn't run in your browser at all. It runs in a cloud VM, the same kind of microVM as this chat, and the tab only shows that remote loop. The VM starts empty and clones your GitHub repository, so the repository is the only way your code can get there. Even if the browser could read your whole disk, the VM is on Anthropic's servers.

Why the desktop app can do both. It is a native app, not a tab, so it may start programs on your machine. For a local session it starts the harness on your laptop, and that harness sees your folders. For a cloud session it asks Anthropic to start the loop in a VM, as the web does. Same window, two possible engines.

This chat is the odd one out. Its harness runs in the cloud, but it can reach your laptop through a bridge when you link it in the desktop app, which then runs commands on your machine on the harness's behalf.

• Where does the loop run? That tells you which files it sees, and whether it keeps going when your laptop sleeps.
• How does the code get there? Either it is already on the machine, or it is cloned in.

The interface changes only how you watch and approve. A harness on the laptop has your real files and stops when the lid closes; a harness in the cloud has only what is in Git and keeps running while you're away.

Not quite. They are the same kind of thing, and files aren't why it is a VM. I called this chat's workspace a container because that is what everyone calls it; the ps output showed its own kernel. It is a microVM, and cloud Claude Code sessions run in the same kind of sandbox.

Files aren't the reason. A plain container handles files fine: it gets its own root file system from the image, and you can write, install and delete anything in it. That is the main thing Docker does.

The reason is who else is on the server. Anthropic runs sandboxes for millions of users on shared machines, and every one runs code nobody reviewed: commands Claude writes, npm install of random packages, scripts from your repository.

• Container: every sandbox on the server uses the same host kernel. The kernel is huge, with hundreds of system calls and a long history of bugs. Exploit one, and a tenant escapes to the host and can reach everyone else.
• MicroVM: each sandbox has its own kernel. To escape, an attacker has to get out of their own kernel and then through the hypervisor⁹⁰ (Firecracker on KVM), which offers only a small, simple set of virtual devices.

Why micro. A full VM emulates a whole PC, BIOS, USB, graphics, and takes seconds to boot. Firecracker strips it to the minimum: about 125 ms and a few MB of overhead, VM isolation at nearly container speed. AWS built it for Lambda, to run strangers' code in bulk.

On your laptop it is neither. claude in your terminal is a plain process running as you, with your permissions. There's no container or VM unless you turn on its sandbox mode. That is why local Claude Code asks you to approve commands: no wall is in the way, so your approval is the check.

A container is enough isolation for code you trust. For strangers' code on shared hardware you want each one to have its own kernel, and a microVM is the cheapest way to get that.

I'm assuming you mean Clawdbot, the lobster agent, now called OpenClaw. Short answer: not by default. OpenClaw doesn't come with a computer. It is a harness you install on whatever machine you choose, and that machine becomes its environment.

• Default: a plain process. Its main program, the Gateway, runs on your machine like local claude. With sandboxing off, tools run on the host: rm or a read of ~/Documents is your real disk.
• Optional: Docker for tools. Turn on its sandbox and the Gateway stays on the host while tools run in a regular container, isolated by Docker's namespaces, with no network by default.

Where people run it decides the rest. A Mac mini at home is real hardware that never sleeps, which fixes the lid-closes problem by buying a computer that stays on. A VPS from Hetzner or DigitalOcean really is a full VM, because of how hosts sell servers, not because of OpenClaw. Some run it in Docker Sandboxes, which make isolated microVMs with a network proxy: the same isolation as this chat.

OpenClaw is the harness; WhatsApp and Telegram are its interfaces; the environment is whatever machine you put it on. That is why there's so much security talk round it: by default the only thing between the agent and your files is your config.

Got it: Grok Bot, from xAI, which now calls itself SpaceXAI. It is almost certainly a VM in xAI's cloud, but whether full or micro hasn't been published. What sets it apart from this chat isn't the kind of VM, it's how long the machine lives and who shares it.

Its page says Bots have their own computer and work while your laptop is closed. You can't host it yourself, and its data page leans on Cursor's sign-on and privacy mode, which fits reports that Cursor supplies the computer underneath.

• Lifetime. This chat's microVM is temporary. Grok Bot's computer is persistent and tied to your account: files, logged-in sessions and tools are there tomorrow.
• Sharing. Here each chat has its own sandbox. Every Grok Bot on an account shares one cloud computer: cookies, files, command-line credentials. Many loops, one environment, no walls between them.
• A screen. It uses a desktop and clicks, so the machine runs a graphical desktop and a browser, not just a shell.

Neither settles full or micro. A microVM can be paused, saved to disk and resumed with everything intact, which makes a short-lived sandbox feel permanent. A desktop is just more software inside the guest. "Full" and "micro" describe how much hardware the hypervisor pretends to have, not how capable the computer looks from inside.

Isolation between your account and other customers is the VM's job, and is probably solid. Between your own Bots it doesn't exist by design: if one is tricked by a malicious page, it is on the same machine as every password the others have used. Grok Bot is a harness in their cloud and one long-lived VM per account; this chat is a harness in Anthropic's cloud and one short-lived microVM per chat.

The conversation lives in a database, not the VM. The model remembers nothing between calls, so every turn the harness sends the whole transcript again, pulled from Anthropic's database. That is why the chat picks up as if nothing happened. If the VM vanished entirely, the conversation would be fine; only my scratch files would be gone.

• Disk only: save the files, throw away memory. Next time, boot fresh and reattach the disk. Running programs are gone; files and packages are there. This is what happened here: a cold boot with Sunday's disk. From inside I can't tell whether the disk was kept attached or restored from a copy.
• Full memory: save the RAM too, so every process and variable resumes mid-step, as if the machine were paused. Firecracker supports this. If it had happened here, uptime would read two days, not zero minutes.

So: yes, idle means the VM shuts down and its CPU and RAM go back to the pool. No, the history wasn't snapshotted with it; it was never in there. Partly: the disk was kept and memory wasn't, which is why a dev server left running gets stopped. Don't count on the disk for ever: the stated rule is that the workspace is reclaimed after a while idle.

Three layers, three lifetimes: the transcript, in a database, kept; the disk, kept for a while; memory, gone when the VM shuts down.

Yes. A harness is needed whenever the model has to do something rather than just reply, and coding is one kind of doing. The loop doesn't care what the tool is: bash and edit_file make a coding agent; web_search, send_email and create_calendar_event make an assistant. What an agent is for comes from its tool list and system prompt.

This chat runs on a harness built on Claude Code. In this conversation it ran ps, searched the web for Grok Bot and drew diagrams with a widget tool, and your Gmail, Notion and Figma connectors are more entries in the same list. Anthropic renamed the Claude Code SDK the Claude Agent SDK because people kept building agents that don't code.

• Run by the harness: bash, file reads, anything that touches the VM.
• Run by Anthropic's API itself: web search is a server tool. The model asks, Anthropic's servers search and feed the results straight back, inside one API call: a small loop on the API's side.
• Run by someone else's server: connectors like Gmail are MCP servers. The harness forwards the call and passes the answer on.

A chat with no tools barely needs a harness: a UI that stores messages and calls the API once per turn. The moment the model can act and see the result before answering, something has to run the loop. Give it a shell and it codes, a browser and it researches, your inbox and it does admin.

Not the copy in your laptop's .claude folder. It is a copy synced from your claude.ai account into this VM, under /root/.claude/skills/synced/…/unmagify/SKILL.md. Two copies, two harnesses:

• `~/.claude/skills/` on your laptop is read by Claude Code when the harness runs on your laptop: the terminal, VS Code, local desktop sessions.
• Skills on your claude.ai account are copied into the cloud VM when a session starts. That is what this chat reads. It can't see your laptop's folder for the same reason it can't see your project.

So if you edit the laptop version, this chat keeps using the old one until you update the account's copy too.

How a [[skill]] gets used, in two steps. At the start, I see only a one-line listing: the harness puts each skill's name and description in my system prompt, which keeps dozens of skills from filling the context. When a request matches a description, I load it: your first question on Sunday matched, so the harness read the full SKILL.md and put it into the conversation. From then on it is part of the transcript sent every turn, which is why my answers here start from the problem and end with "The pattern".

One conflict worth fixing: the skill says to draw small text diagrams in code blocks, and your saved preference says real flowcharts with few colours. I followed your preference, as it is more specific to you; the skill could be updated to match.

A skill is a Markdown file the harness reads lazily: the description always visible, the instructions loaded when needed. Which copy is read depends on where the harness runs.