Everything that makes CRAFT feel like CRAFT works in the browser. What changes is anything that quietly assumed a hard drive. Here’s what we found when we tested the framework against itself — and the one fix that ties the whole thing together.
Most of CRAFT for Claude Cowork was authored in an environment with a filesystem, git, and a shell sitting under it — Claude Code, or the desktop app with its bridge to your local files. The web version of Cowork is a different animal: your session runs in a cloud sandbox in your browser, with no permanent home on your own disk. That difference is the entire question this report set out to answer. Which of CRAFT’s assumptions survive in the web version, which bend, and which break outright — and what you should actually do about it?
Rather than guess, we tested. And because this is CRAFT, we tested the CRAFT way.
Using CRAFT to test CRAFT
CRAFT’s own QA & Validation Framework (CD-011) is built on one stubborn principle: observation-first. You never trust the model’s memory for the state of the world. You capture ground truth by actually running the thing, then compare what happened against what you expected. Its test-deploy loop adds two more habits worth stealing — treat the environment as a real first-timer would (no coaching it toward success), and log every issue as a structured Finding Report rather than quietly working around it.
So that’s what we did. We booted a CRAFT session in web Cowork, ran a plan across two phases — first probing the raw platform capabilities CRAFT leans on, then exercising the core session-lifecycle recipes as a brand-new user — and wrote down our findings, each with a severity and a reproducible observation behind it. Across the original run and two follow-up sessions the tally grew to fifteen: seven clean passes, one pass with a caveat, five partials, one genuine break (later proven airtight, as you’ll see), one not-applicable. Nothing below is asserted from intuition; every claim traces to something we watched happen.
The headline: the sandbox forgets
Start with the finding that matters most, because it reframes everything else. When you work in web Cowork, your files live in a cloud container that is spun up for the session and reclaimed afterward. Within a single session it is rock-solid: files we wrote at boot were still there many turns later, exactly as written. But a new session gets a new container. Anything CRAFT wrote to disk in the last session — including the whole CRAFT Project Files/ tree — is simply gone.
That collides head-on with how CRAFT normally preserves continuity. The handoff-snapshot recipe (RCP-001-001-002) writes a state file to disk so a future chat can pick up where you left off. On desktop that’s perfect. In the web version, a disk-written snapshot doesn’t survive to the next session, so the resume never happens. We rated this a B1 — the most severe class — because left unaddressed it breaks CRAFT’s multi-session story entirely.
The good news is that it has a clean, proven fix, which we’ll come to. But it’s the thing to internalize first: in web Cowork, disk is scratch space, not memory.
We didn’t leave that claim resting on a single glance. Across three separate sessions we hardened it into an airtight proof. The first session merely inferred the container was ephemeral. The second booted into a fresh container and watched the previous session’s files be gone — suggestive, but a skeptic could object that we simply hadn’t re-uploaded them. So that second session planted a beacon: it had CRAFT itself write a uniquely-named file directly to the sandbox disk, then recorded that file’s exact path and SHA-256 hash in the Project. A genuine third session, opened later, tried to read that path before writing anything to disk — and found nothing, on a container only minutes old, while the Project’s record of the beacon read back perfectly. Because CRAFT created that file itself rather than us re-providing it, “you forgot to re-upload” stops being an available explanation. The disk really does die between sessions; the Project really does survive. That is the single fact the rest of this report is built on.
What works — the whole CRAFT “feel”
Here’s the reassuring half. Everything that makes CRAFT recognizably CRAFT runs in the web version without modification:
- The boot sequence. CHAT-INIT loaded the project brain, ran a full SHA-256 integrity check over the framework (150 of 150 core files verified), and activated the operations persona — end to end, first try.
- Personas and comment styling. The persona layer held across every turn of the session, including the persona-aware comment format. This is fully functional in the browser.
- File work. Read, write, edit, re-read — all fine. The shell CRAFT expects is present, and generously stocked: bash, grep, sed, awk, sha256sum, unzip, plus python, node, and jq.
- Integrity verification. The SHA-256 manifest check — CRAFT’s way of proving the framework hasn’t drifted — works perfectly, and is arguably a better ground-truth anchor here than git (more on that below).
- HTML artifacts. CRAFT’s shipped info-blocks and styled outputs render in the side panel. (This very post is the proof.)
- Project scaffolding. The project-file generator produces valid CRAFT Project Files in-session without complaint.
If your CRAFT work is contained within a single working session — invoke a recipe, produce a document, style an output, run a validation — the web version handles it just like desktop. The language, the personas, the recipe engine: all intact.
What bends or breaks — the disk-assumption layer
Every remaining issue has the same root cause: it assumed a persistent local disk that the web version doesn’t provide. Grouped by what you’ll actually hit:
Cross-session continuity (B1 → fixable)
Covered above. Disk-based handoff and resume don’t carry across sessions. Fixable by re-homing state to the Project.
The drag-drop upgrade model (B2)
CRAFT’s two-folder layout normally upgrades by dragging a fresh CRAFT Core Files/ over the old one on a persistent mount. The web version has no such mount, so there’s nothing to drag onto. In practice you re-provide the framework at the start of a session (upload the current release) rather than upgrading in place — or you treat the Project as your canonical store and load Core from there.
Git-based ground truth (B2)
Two of CRAFT’s grounding checks capture git branch, HEAD, and diffs to verify state. When your CRAFT install is an uploaded folder rather than a cloned repository, those commands have nothing to read — we confirmed the expected “not a git repository” failure directly. It degrades honestly rather than lying, and the SHA-256 integrity check plus a file inventory still deliver a perfectly good non-git ground truth. If you want the git half back, keep your install inside an actual repository.
Local-file access via the device bridge (N/A in pure web)
In a pure browser session with no desktop app attached, the bridge to your local files isn’t present — we confirmed the tools simply don’t exist in that context. Any recipe that expects to reach your on-disk CRAFT install or local documents can’t, unless you connect the Claude desktop app to bridge them. Otherwise, work from uploads and the Project.
Token metering (B3)
The token monitor assumes it can watch context-window usage and warn you at 70 / 85 / 90%. In the web version, nothing exposes the true live token count to the session, so the monitor can only estimate from the conversation so far. Treat its warnings as a heuristic, not telemetry — and snapshot earlier than you think you need to rather than trusting an auto-handoff to fire at a precise threshold.
The Operations Manager’s auto-suggest (B3)
Worth being candid about: the Operations Manager that “automatically detects and suggests recipes” is a convention the model follows each turn, not a background process standing guard. It works well when the session is fresh and focused, but CRAFT’s own framework names the risk — degradation under token pressure — and this is exactly where it shows. Lean on it, but don’t treat it as a guarantee; invoke recipes explicitly when it matters.
The one fix that ties it together
Notice that the breakages aren’t six unrelated problems. They’re one problem wearing six hats: state that needs to outlive the session has nowhere permanent to live. Which means there’s a single fix.
Treat the claude.ai Project as CRAFT’s durable mount.
Anything that must survive to the next session — your handoff snapshot, your project state, your lessons learned, the framework release itself — gets written to the Project, not the sandbox. The Project is the one surface we confirmed round-trips reliably: we wrote a document, read it back intact with a server timestamp, and it was still there in a way disk never would be.
We didn’t just recommend this — we exercised it. The session handoff for this very test was written to the Project, and a future session can boot straight from it. The disk-based resume is broken; the Project-homed resume works. Same recipe, durable address.
Reframed that way, the web version stops looking limited and starts looking like a platform with a different — arguably simpler — persistence model. You don’t manage a mount, back it up, and drag folders around. You keep the durable stuff in the Project, where it’s also visible across your devices and to your team, and you let the sandbox be fast, disposable working space.
The mount has a ceiling — and a trick to fit the release inside it
There is one more thing to know about that durable mount, and it took a fifteenth finding to pin down: the Project is not infinite. Its knowledge store caps at roughly 2 MB — you can read the exact ceiling yourself as max_knowledge_size in the project info. For CRAFT’s derived state — handoff snapshots, findings, lessons, restore notes — that’s enormous headroom; those artifacts are kilobytes. The question is whether you can go further and park the framework release itself in the Project, so a returning session never has to re-upload it at all.
We tried, and the answer is a useful “it depends on the edition.” Two approaches failed for the large Admin edition. Uploading the raw .zip as a Project file was rejected outright — the Project accepts text and document uploads, not arbitrary binaries. Encoding the whole Admin release as one big base64 text document did write, but it drove the knowledge store past the 2 MB ceiling, at which point the document wouldn’t even read back; we had to delete it to bring the Project back to health. The Admin edition is simply too big: about 10.5 MB as loose text, 2.9 MB zipped, 4 MB once base64-encoded — over the cap every way you slice it.
The smaller User edition, though, fits — with a subtlety that is the whole trick. Stored as loose text its files total about 3 MB, which is over the cap. But base64-encoding the compressed zip — not the unpacked files — lands at roughly 1.2 MB, comfortably under. Compression is the deciding factor: you encode the zip, not the folder. When we did that, the stored document round-tripped byte-for-byte — we read it back, decoded it, and the reconstructed zip’s SHA-256 matched the original exactly, then re-passed the framework’s own 61-of-61 integrity manifest. For the User edition, that means you store the framework in the Project once and never upload it again; a future session pulls it back down, decodes it, and verifies it in seconds.
Putting it to work: a first-run prompt anyone can use
Everything above collapses into something practical: a single prompt you can paste on your very first session with the CRAFT User edition in web Cowork. It teaches Claude how the ephemeral sandbox behaves, stands the framework up, stores the release in the Project so you never re-upload it, and leaves behind a restore note that lets any later session boot CRAFT with nothing but the Project attached. It’s deliberately generic — no persona, no project-specific identifiers — so you can hand it to anyone running the User edition and it will just work.
Attach your CRAFT User edition .zip to a chat that is connected to a Project, then paste this in and send:
We're running CRAFT for Claude Cowork (the User edition) inside the WEB version of Claude
Cowork, and this is our first session. Please read this whole message before doing anything.
I've attached the CRAFT User edition release as a .zip file.
GROUND TRUTH ABOUT THIS ENVIRONMENT — treat these as facts, not guesses:
1. The web Cowork sandbox is EPHEMERAL. Every new chat gets a fresh cloud container with a
blank disk. Anything written to disk — CRAFT's own files, any handoff snapshot — is gone
by the next session. Do not rely on disk to carry state across sessions.
2. The claude.ai PROJECT attached to this chat is the ONLY surface that persists across
sessions. It is CRAFT's durable "mount." Nothing lands there automatically — it's a
deliberate save, so you must explicitly write anything that must survive.
3. The Project has a size limit: its knowledge store caps at ~2 MB. Check it via project_info
(max_knowledge_size). The User edition fits; the larger Admin edition would not.
4. There is no live token telemetry in web, so any CRAFT token monitor is estimate-only.
Checkpoint important state to the Project early rather than waiting for a threshold.
WHAT TO DO THIS SESSION, IN ORDER (give me a short status after each step):
STEP 1 — Stand up CRAFT.
Extract the attached zip in the sandbox. Read the release's own entry docs (START-HERE.md
and CLAUDE.md) and follow its boot instructions. Then verify integrity: in the
"CRAFT Core Files" folder run sha256sum -c SHA256SUMS and report the pass/fail count
(expect every file OK). Report the total file count too.
STEP 2 — Make the release survive future sessions so I never re-upload it.
Because the disk is ephemeral, store the release itself in the Project:
a. base64-encode the ZIP (the compressed zip, not the loose files — compression is what
keeps it under the ~2 MB cap): base64 <release>.zip > craft-release.b64.txt
b. Write that base64 file into the Project as a text doc (a durable save).
c. VERIFY THE ROUND-TRIP before trusting it: read the doc back out of the Project,
base64 -d it, and confirm the decoded zip's SHA-256 matches the original zip's SHA-256
exactly. Then re-extract it and re-run sha256sum -c SHA256SUMS (all OK). Also confirm
in project_info that knowledge_size is under max_knowledge_size.
d. If the base64 would exceed the ~2 MB cap, DO NOT store it — tell me, and we'll just
re-upload the zip each session instead.
STEP 3 — Leave a restore note in the Project.
Write a short Project doc recording: the Project path of the base64 release doc, the zip's
SHA-256, its file count, and the exact steps to reconstruct it
(project_read the base64 doc -> base64 -d -> verify SHA-256 -> unzip -> sha256sum -c
SHA256SUMS). This is what a future session follows to get CRAFT running with no re-upload.
STEP 4 — From now on, treat the Project as CRAFT's durable mount.
Write anything that must outlive this session — handoff snapshots, project files, lessons —
to the Project, never only to disk. Keep each durable write small (mind the ~2 MB cap) and
verify large writes by reading them back.
RESUMING LATER: in a future session I'll attach this same Project. To bring CRAFT back with no
upload, read the restore note you wrote and follow it. If the release doc is missing or the cap
was exceeded, ask me to re-attach the zip.
Please start with Step 1.
What the prompt does, step by step
The opening block is the part people skip and shouldn’t: it hands Claude the four environmental facts it cannot discover on its own. Claude has no way to know from inside a session that its disk is disposable or that the Project caps at 2 MB — those are properties of the platform, not of the files in front of it. Stating them up front prevents the most common failure mode, where Claude cheerfully writes a handoff to disk and it evaporates before anyone notices.
Step 1 is ordinary CRAFT boot, with one non-negotiable: run the SHA-256 manifest check and report the count. This is the framework proving to you it arrived intact, and it doubles as the baseline you’ll compare against later when you reconstruct the release from the Project. Step 2 is the persistence move — encode the compressed zip to base64, write it to the Project, and then verify the round-trip. That verification is not ceremony. A Project write can report success and still be unreadable if it pushed the store over the ceiling, so the only way to know the release is genuinely safe is to read it back, decode it, and confirm the hash matches. Step 3 writes the instructions a future session needs, so restoring CRAFT is a mechanical checklist rather than a puzzle. Step 4 generalizes the discipline to everything else CRAFT produces: durable things go to the Project, small, and verified.
Why it’s built this way
Two decisions in the prompt are load-bearing and worth calling out, because they’re the parts you’d get wrong if you wrote it from intuition. First, it base64-encodes the zip rather than the unpacked files — because compression is exactly what pulls the User edition under the 2 MB cap, and encoding the loose folder instead would blow it. Second, it forces the read-back-and-hash-check, because “the write succeeded” is not the same as “the data is retrievable” when a size ceiling is in play. Everything else in the prompt is just being explicit — naming the facts, ordering the steps, and telling Claude what to do at the one branch point (release too big for the cap) so it degrades gracefully into per-session uploads instead of failing silently.
How to use it, and what to expect afterward
Open a Claude Cowork chat that is attached to a Project — that attachment is what gives CRAFT its durable home, and without it the whole scheme has nowhere to persist. Attach your User edition .zip, paste the prompt, and send. Claude will stand CRAFT up, verify it, store it in the Project, and leave the restore note. From then on, any new session on that same Project can bring CRAFT back with no upload at all: it reads the restore note, pulls the base64 document, decodes and verifies it, and you’re working again in under a minute. If you ever ship an updated release, re-run Step 2 to replace the stored copy and re-verify the round-trip. And if you’re on the larger Admin edition, everything in the prompt still applies except the storage step — that edition exceeds the cap, so you’ll keep re-uploading it each session while still homing all your derived state in the Project.
A practical checklist for web Cowork
- Keep all project state in the Project; treat the sandbox as scratch.
- Store the release in the Project too if it fits the ~2 MB cap — base64-encode the zip (not the loose files) and it survives; the User edition fits, the Admin edition doesn’t.
- After any large Project write, read it back and check the hash — a write can succeed yet be unreadable if it blew the cap.
- Write handoff snapshots to the Project, and boot new sessions by reading them back.
- Don’t rely on the token monitor’s exact thresholds — snapshot early.
- Expect git-grounding to be inert unless your install is an actual repo; lean on the SHA-256 integrity check instead.
- Need local files or in-place upgrades? Connect the desktop app for the bridge; otherwise upload the release each session.
- Invoke recipes explicitly when it matters, rather than assuming the Operations Manager will catch every opening.
Bottom line
CRAFT for Claude Cowork runs well in the web version. The entire language-and-recipe experience — the part you actually think of as CRAFT — is intact and unmodified. The only real adjustment is a mental one: the browser sandbox has no long-term memory, so the claude.ai Project is where CRAFT’s memory lives. Make that one move, and the framework’s continuity, upgrades, and grounding all fall back into place. Skip it, and you’ll rediscover the ephemeral sandbox the hard way, one lost handoff at a time.
And once you’ve made it, the first-run prompt above turns the whole lesson into something you can hand to the next person: paste it, and CRAFT stands itself up, remembers itself in the Project, and resumes without a re-upload. The ephemeral sandbox stops being a limitation you work around and becomes just the fast, disposable desk you happen to be working at — with everything that matters kept safely in the drawer.
Tested against craft-admin-v.b0001.p202607.01a (Admin) and craft-for-claude-cowork-v.b0001.p202607.01a (User) in the web version of Claude Cowork, using CRAFT’s own observation-first QA method (CD-011). Fifteen findings across three sessions; the ephemeral-disk finding proven airtight with a cross-session beacon, and the release-persistence method verified by byte-for-byte round-trip. Full ledger and restore protocol on file.
