The Many Faces of Claude

Part I chapter draft, v0. The roster of surfaces a developer meets Claude through, what each is good and bad at, and how to choose. Two things make this chapter earn its place beyond a product tour: the cross-surface handoff problem (why moving work between faces goes wrong, and the one thing that makes it go right), and the economics of surface choice (subscription vs. API is a selection criterion, not a footnote). Perishable by design — the roster churns, so the durable content is the selection criteria and the failure modes, and the product table is maintained on the companion site.

The one-sentence version

Claude has many faces, they do not share a brain, and picking the wrong one costs you more time than picking the wrong prompt.

Why “faces” and not “clients”

Under the hood several of these run the same engine. That fact is a given, and it is not the point. The point is that each face is a different way to interact with Claude — a different UI, a different set of things it can reach, a different set of things it forgets, a different bill. A distinction that is architecturally thin can be enormous in practice.

Two entries on the roster make the case:

• claude -p is technically a flag on the CLI. But almost nobody who uses the Claude Code CLI interactively thinks of headless invocation as a thing they could do, and that blind spot is expensive — it is the difference between using Claude as a tool you sit in front of and using Claude as a subroutine inside your own software. Presenting it as its own face is the only way to make that visible.
• Desktop chat and web chat are close cousins. They still get separate entries, because from where you sit they are two different applications, with two different histories, that do not reliably share your projects with each other.

If you already know which face you are in and why, skip to the handoff section — that is the part experienced developers get wrong too.

The roster

The eight you will actually choose between

The rest of the roster

Real faces, lower usage share for most readers — a line each, not a section each:

Reading the roster more than one way

A single ordering can’t explain these. The same eleven-plus faces sort differently depending on which question you’re asking, and each sort answers a different real decision.

Axis 1 — Reach: what can it actually touch?

The most consequential axis, and the one beginners never think about. A face that can’t see your repo will confidently advise you about your repo.

The Chrome Extension column is the one nothing else can fill: it is the only face that inherits your authenticated sessions. That is its entire reason to exist.

Axis 2 — Attendance: who is watching?

The book’s supervision argument (Chapter 4) assumes somebody is watching. As you move right on this axis, that assumption fails, and the control stack (Chapter 7) has to carry the whole load — gates, not guidelines.

Axis 3 — What it leaves behind

Underrated until it bites you.

Author’s field fix: the Chrome Extension’s lack of a durable transcript was costly enough that every extension session now starts by being handed a fresh Gist to write anything useful into. That is a workaround for a missing artifact, and it generalizes: if a face doesn’t leave an artifact, give it one.

Axis 4 — What configures it

The friction nobody warns you about: Claude Code CLI and Claude Code Desktop read the same CLAUDE.md, and there is no clean way to give them different instructions. That matters the moment a project has CLI-only tooling — a task-tracking CLI that exists in the terminal and not in the desktop app — because the shared file is now telling one face to use a tool the other face can’t reach. Faces are separate; the configuration surface is not.

Axis 5 — Who pays, and how

Covered properly in Chapter 12, but it belongs on this list because it is a live selection criterion, not an afterthought. The working method behind this book is to stay on a subscription rather than run up four-figure API bills, and that constraint decides which face opens for which job. A reader who never thinks about this ends up paying per-token for work a subscription face would have done.

The eight, one at a time

Percentages are the author’s own measured usage — offered as one working developer’s real distribution, not a recommendation.

1. Claude Code CLI — ~75%

The default. Everything else on this list is an exception to it.

Strengths: the full control stack lives here — CLAUDE.md, skills, hooks, permission modes, MCP, and your own CLIs. Durable, resumable, greppable transcripts. Git is right there. Parallelism via worktrees (Chapter TK) is only really practical here. It composes with your own tooling instead of asking you to work inside its box.

Weaknesses: terminal literacy is a real barrier for the primary reader of this book. No visual affordances. It is the face where “auto-approve everything” has the largest blast radius.

2. claude -p — used constantly, but indirectly

Claude as a subroutine. Not a thing you sit in front of; a thing your software calls.

The archetypal use is a CLI command that needs a judgment call in the middle of otherwise deterministic code — does this filed task actually contain everything needed to implement it? or, trivially, is this word a verb, and if so what’s its definition? The AI is one step inside a deterministic pipeline, not the pipeline.

This is the direct operational cousin of Chapter 6: keep the deterministic parts deterministic, and call the model only at the step that genuinely requires judgment. It’s also why Chapter 8 matters — the thing on the other end of claude -p is a program, so the interface has to be built for a program.

Weaknesses: no human in the loop, so everything the supervision model assumes is gone. Non-determinism inside a script you’ll trust later. Costs accrue invisibly.

3. Claude Code Desktop — ~5%

Development-adjacent project work. The trigger is: it’s a real project with real files, but it isn’t going through the development task-tracking workflow — this book being the example. Some coding happens; it isn’t a coding project.

Strengths: the coding agent’s competence with a GUI’s approachability. The right recommendation for a capable non-developer who won’t live in a terminal.

Weaknesses: shares CLAUDE.md with the CLI while not sharing the CLI’s tooling (see Axis 4). Weaker fit for anything that wants worktrees or heavy shell work.

4. Cowork Desktop — part of the “all others” ~5%

Agentic work on your computer, not in your codebase. The reason to open it is Computer Use: renaming a pile of documents, pulling information out of Notes and producing a report — real work that has nothing to do with a repo.

Weaknesses: the honest note is that low usage means low knowledge. This is the face most likely to have capabilities the author hasn’t found yet, and the section should say so rather than pretend to a survey it hasn’t done.

5 & 6. Desktop Chat and Web Chat — Web ~10%

Web chat is for questions and for long-running research — things that don’t belong as a tracked development task. It’s the thinking surface.

Strengths: no setup, best-in-class for open-ended research, and cheap in attention.

Weaknesses: the big one is invisible context asymmetry — see the next section. Web chat gives excellent advice about a codebase it has never seen, in exactly the same confident register it uses for things it has verified.

Desktop chat is web chat plus local reach — filesystem, MCP, connectors. Whether that gap matters to you depends entirely on whether you’ve wired up connectors. And the two do not reliably share projects, which is a genuine day-to-day irritation rather than an architectural nicety.

7. Web Cowork

Cowork’s model without the local machine underneath it. Include for roster completeness; the author’s usage is thin enough that a confident strengths-and-weaknesses treatment would be invented rather than observed.

8. Claude Chrome Extension — ~5%

The only face inside your authenticated browser session. Two jobs: automating a site you have to be logged into, and researching one.

Real example: auditing and initially configuring an AWS account through the console, then moving to the AWS CLI for everything after. And a nice illustration of why the face exists at all — when a suggested command bricked the CLI’s own credentials, the extension was the way back in, because it could drive the console as a logged-in human would.

Weaknesses, and they’re sharp:

• No durable transcript (hence the Gist workaround above).
• The busy-body problem. It wants to insert itself into everything. Getting its output usefully into another session turned into an ordeal — which leads directly to the next section.

The cross-surface handoff problem

This is the part of the chapter that isn’t in any product documentation, and the part experienced developers get wrong too.

The symptom

The obvious workflow is: have web chat do the research, then have the CLI read the research and plan the work. In practice this is frustrating nearly every time. The CLI session either argues with the recommendations or takes them too literally and has to be talked off a ledge. Something that should have been a clean handoff becomes a negotiation.

The mechanism

Every session assumes it is the center of the world. A session has no representation of “there is a context I can’t see.” Web chat, with no access to your files, your repo, or your task history, produces recommendations in exactly the same confident register it would use with full visibility — because the gap is invisible from the inside. The receiving session then has a second problem: the incoming text arrives with no marked standing. Nothing in a pasted block distinguishes a considered decision you have made from a brainstorm produced by an agent that couldn’t see the code. Facing an unmarked instruction, the receiving session guesses — and both guesses are wrong. Over-defer and it implements a bad plan faithfully; under-defer and it relitigates a decision you already made.

This is the same failure the rest of the book keeps naming, arriving through a new door: a frame is inherited and never re-derived (Chapter TK), and the additive default fills the gap with more (Chapter 9).

The thing that makes it work

The exception is instructive. Handoffs through a task-tracking system — one session files a task, another picks it up and implements it — are dramatically better. Not perfect, but not in the same league of frustration.

The plausible reason is that the task path has something the prose path doesn’t: a shared protocol. The task is a known artifact, in a known slot, in a workflow whose ground rules both sessions read (in the author’s setup, a guide command the CLI exposes). The receiving session doesn’t have to guess at standing, because the artifact’s format carries it.

The generalizable law is worth stating plainly:

A handoff between faces succeeds in proportion to the shared protocol at both ends. Prose has none. An artifact with rules has some. This is Chapter 7’s guideline-vs-gate distinction applied to the seam between sessions.

The practical moves:

1. Prefer handoffs through an artifact with a defined shape over handoffs through pasted prose.
2. Mark standing explicitly when you must paste. “This is research from a session that could not see the code — treat it as input, not as decisions” costs one sentence and prevents both failure modes.
3. Expect the receiving session to need the frame re-derived, and give it the job explicitly rather than hoping.

Choosing a face

Ask in this order:

1. What does it need to reach? Your repo, your Mac, a logged-in site, or nothing but a conversation. This eliminates most of the roster immediately.
2. Will anyone be watching? If no, you need gates, and only some faces have them.
3. Does it need to leave a record? If yes, avoid the faces that don’t, or hand them an artifact to write into.
4. What pays for it? Subscription-covered work should not silently become API-billed work.
5. Will its output have to travel to another face? If yes, plan the protocol before you start, not after.

For the reader who isn’t a developer: the Claude Code CLI, if you can and are willing. Not because terminals are virtuous, but because that’s where the mechanisms this book teaches actually exist — the control stack, durable transcripts, git right there, and the best value from a subscription. If the terminal is a genuine wall, Claude Code Desktop, and the rest of the book still applies with a small tax.

Auto mode, and what actually makes it safe

The chapter just routed you to the most powerful face. The obvious next question is how much rope to give it — whether to approve each action or let Claude act on its own.

Auto mode is a genuine productivity unlock, and this book won’t pretend otherwise; it is a large part of why the CLI is worth the learning curve at all. It is also not the shipped default, and the honest reading of that is not “the vendor is getting comfortable” — it is “the safe answer for the median user hasn’t been settled.” The median user is this book’s primary reader. So the recommendation has to rest on something a reader can verify for themselves.

It does. Auto mode is not a courage setting, it is a containment setting. The question was never whether you trust Claude. The question is what happens when it is wrong — and that is a property of your setup, not of your nerve. Reduce the harm surface first and auto stops being a gamble.

The containment ladder

Cheapest first. Every rung is worth taking on its own; the point is that auto mode gets safer as you climb.

1. Commit clean before you start. Anything committed that goes wrong is one command from undone. Seconds of cost, and the highest-return move on the list — the whole argument of Chapter TK applied to a single decision.
2. Work on a branch. History isolation: the mess stays off your main line.
3. Work in a worktree. Working-tree isolation — the worst case is a directory you delete. Chapter TK presents worktrees as the substrate for parallelism; containment is their second job, and in this author’s practice it is the specific thing that makes running everything on auto reasonable rather than reckless.
4. Sandbox the process. Constrains what Claude can reach outside the repo.
5. A container, a VM, or a cloud session. Not your machine at all.

What the ladder does not cover

This is the real boundary, and it is where a non-developer is most likely to get hurt.

Git protects the things that are in git. It does not undo a dropped database table, a modified cloud account, a sent email, a pushed commit, or a deleted file outside the repo. That is precisely the surface Chapter TK names as the part that cannot be regenerated, and it is where auto mode’s risk actually lives — not in a bad edit, which is trivially reversible, but in a command against something with no undo.

The AWS story from the Chrome Extension section is the illustration: the command that bricked the CLI’s own credentials was not a file edit, and no amount of git hygiene would have caught it.

The shape of the recommendation

Auto in proportion to containment.

Full auto, in a worktree, on a committed repo, with no production credentials in reach — reasonable, and the speed is real. Full auto in your main working folder, with your cloud credentials loaded and an uncommitted afternoon of work sitting there — that is not trust, it is exposure, and Claude being good at its job does not change it.

For a reader coming to the CLI without a development background, the good news is that the cheap rungs are also the accessible ones. Commit before you start requires no new concepts beyond Chapter TK, and it converts most of the scary scenarios into an inconvenience.

The evidence behind this, stated honestly

This author runs everything on auto and has had good results. Two things make that less of an endorsement than it sounds, and both are worth saying out loud.

The top of the ladder is untested here. Rungs 1 through 3 — commit clean, branch, worktree — are in constant use. Sandboxing and containers are not; containers are a planned addition to the author’s own tooling, not a practice being reported on. A ladder is being recommended whose upper rungs the recommender has not needed.

The risk surface is small. There is no payment processor in the loop, no hosted production database, no cloud provider running up a bill — no paid online service at all beyond Claude itself. Nearly everything that could go wrong is a file, and files are in git. That is not the situation of a reader who has shipped something with real users and real credentials attached.

Which is the framing working, not an exception to it. If the right rung is a function of your exposure, then a small exposure needing only the cheap rungs is exactly what the rule predicts — and a reader with a payment processor, a production database, and a cloud account should climb higher than this author has ever needed to, precisely because the ladder is calibrated to the blast radius rather than to anybody’s comfort level.

Open questions

• Placement within Part I. Drafted as the part’s opener, on the argument that every later chapter’s advice is conditioned on which face you’re in, and a reader arriving from vibe coding has used one face without knowing the others exist. The alternative is next to the Ecosystem Map — that chapter tours products you choose between, and so does this one.
• Chapter or section. Drafted as a chapter; demotes cleanly to a long section if Part I gets crowded.
• Is the containment framing too strong for Part I? The auto-mode section resolves the question by making containment the variable rather than nerve, which is the right answer but arguably a Part III argument arriving in Part I. Alternative: keep two paragraphs and the ladder here, move the boundary discussion next to Chapter 7 or Chapter TK. Also unverified in the draft: whether Claude Code Desktop offers the same permission posture as the CLI, which matters because that is where non-CLI readers get routed.
• How much Cowork deserves. Two entries are honestly under-explored. Either invest a week of real usage or keep the sections explicitly short and say why.
• Does the handoff law hold outside the author’s setup? The task-handoff-works finding is n=1 on one toolchain. The mechanism is general; the evidence is not. Worth either a second data point or an explicit hedge before it ships as a law.

Facts to verify before publish

The roster is the most perishable content in the book. Before any release, re-check against current documentation: which faces exist and under what names; which are subscription-covered vs. API-billed; Cowork’s actual capability surface on desktop and web; whether project/history sharing between faces has improved; whether per-face CLAUDE.md differentiation has landed; and the current state of cloud Claude Code sessions and scheduled agents. The companion site carries the maintained table; the print edition should lean on the criteria.

Found something wrong, unclear, or plainly disagreeable? Open an issue