See it work
Every image on this page came out of a running v10.0 install in a real Google Cloud project. Nothing here is a design comp, a staged terminal or a recorded happy path. Read them in order: a strain writes a service, builds the container, deploys it to Cloud Run, then goes back round the front door as an anonymous caller to check that the thing it just built actually answers.
Screenshot 01
The shortest honest demo of the whole product. One window, two halves: the conversation that asked for a thing, and the thing, served from your own project on a URL you can open.
03-build-a-calculator.png — console chat left, the deployed calculator right.
Left pane: the Flow Hood, the console chat. A human asked for a calculator. The strain wrote the source, wrote a container definition, ran the build, deployed the resulting image to Cloud Run, and printed the service URL back into the thread. Right pane: that URL, loaded. Buttons, arithmetic, a live service. Not a canvas rendering of a calculator inside the chat — a separate Cloud Run revision with its own address.
Three things, and they are the three that matter.
It reaches the substrate. The strain is not producing a suggestion for you to paste into a terminal. It holds scoped identity in your GCP project and it drove Cloud Build and Cloud Run with that identity. The artefacts it made are in your project, on your bill, under your IAM.
It closes the loop. After deploying, the strain fetched the new URL anonymously — no credentials, the way a stranger would — and reported the HTTP status code it got back. That is the difference between "the deploy command exited 0" and "the service answers". A deploy that returns success while the container crash-loops is the single most common lie in automated infrastructure, and an anonymous verification is what catches it.
It is attributable. Every step in that thread ran as a named strain with a role, and the journal holds who staged the job, the exact command, and what it returned. You can go back later and read it. The screenshot is a moment; the journal is the record.
install.sh sets
PC_AUTO_APPROVE=1. The job was staged, KMS-signed and executed in the same call —
there is no per-job passkey tap in this product, and the console page that once offered one was
deleted. The signature covers a pinned approved_sha256 of the command, so an edited
command is refused. Set PC_AUTO_APPROVE=0 and a staged job lands in
pending and does not run: not on a timer, not on a retry, not ever. The product stops.
It does not ask.
Screenshot 02
The calculator is the impressive one. This is the diagnostic one: the same build-and-deploy pipeline with the application logic reduced to nothing, so you can see the plumbing.
01-build-and-deploy.png — build, deploy, verify, 200 OK.
A strain taking a trivial service from nothing to a served URL, narrating each stage in the thread: source written, image built, revision deployed, URL fetched, status code reported. The interesting content is the sequence, not the payload. Strip the app down to a string and what is left is the machinery.
That the pipeline is real and repeatable rather than a one-off that happened to work for a calculator. It also shows the failure surface honestly: each stage is a distinct step with its own output, so when something breaks you learn which stage broke. A build failure and a deploy failure and a cold-start crash look nothing alike in that transcript, and none of them look like success.
The 200 at the end is not the deploy tool's opinion of itself. It is a fresh,
unauthenticated request against the public URL. If the revision came up unhealthy you would be
reading a 503 in that same line, in the same chat, seconds after the deploy claimed
to have worked.
Screenshot 03
The demo above is what a strain can do. This panel is where you decide what it may do, with which substrate, under which identity, and who is allowed to open the door at all.
02-strain-settings.png — theme, substrate, key rotation, session pastes, allowed accounts.
The settings surface for a strain and for the install around it. Five groups of control, and four of them are security posture wearing a friendly label.
iss, exp and aud pinned, and X-Goog-Authenticated-User-Email is never trusted on its own.That the controls are in the product, not in a runbook. The allowed-accounts list is the clearest
example of the distinction this whole system is built on. Underneath it sits the org policy
constraints/iam.allowedPolicyMemberDomains: an out-of-domain account is refused
at binding write, not at request time. Writing "do not grant access to personal accounts" in
a wiki is a policy, and somebody eventually does it anyway at 2am. Refusing the write is a control.
The substrate selector proves the tenancy claim in one field. There is no Paracoding tenant your state gets written to, because there is no field anywhere in this panel that points at us. Nothing phones home. If you delete the project, you have deleted the install.
PC_AUTO_APPROVE=1,
PC_GUARDRAILS=0, PC_REQUIRE_PASSKEY=0. Setting
PC_GUARDRAILS=1 restores two runtime refusals. Setting
PC_REQUIRE_PASSKEY=1 re-arms the whole WebAuthn layer, which is still entirely in the
tree — HMAC-SHA256 cookies, fail-closed on a weak secret, 401-in-place with no redirect and no
?next= enumeration oracle.
Screenshot 04
Launch day: the console open beside Claude Max in Cowork. This is not a testimonial. It is the working arrangement that produced the code you are being asked to install.
04-built-with-claude.png — launch day, the console beside Claude Max in Cowork.
A human and a fleet of strains working on the harness with the harness. The console on one side holding the work-item queue, the journal and the git store; a Claude session on the other side connected over MCP, reading and proposing against that same state.
That the loop closes on itself, which is the only stress test that never lets up. The serverless git
implementation is not a demo of serverless git — it is where this repository lives. Isomorphic-git
inside Cloud Run over a split backing store: refs, HEAD, config, .git/index,
packed-refs and the working tree as Firestore documents, objects in GCS. Compare-and-swap
is lifted above isomorphic-git into a Firestore transaction, because the library's native
writeRef is a blind overwrite and its AsyncLock is an in-process mutex
worth nothing across Cloud Run instances. A ref resolver guarantees every call into the library receives
a resolved 40-hex OID. Push outcomes are classified, not retried:
ALREADY_EXISTS NOT_FOUND
STALE. There is no force push. It scales to zero.
Every one of those decisions exists because a strain hit the failure it prevents, in this repo, while doing this work. That is a different provenance from a feature designed in a planning document, and it is the reason the sharp edges are documented rather than smoothed over.
The console
Five surfaces behind one IAP-protected front door. The screenshots above are two of them; here is the rest of the set and what each one is for.
The human front door, printed at the end of install. Google IAP sits in front of it and the
ES256 assertion is verified server-side against Google's JWKS with iss,
exp and aud pinned; a cold JWKS cache fails closed. Everything below
lives under this path.
Where you talk to a strain, and where the calculator and the hello-world in the screenshots above were built. Each strain carries its own identity and role, so what you can ask for and what comes back are both scoped. A leaked key leaks a role, not the system.
The memory graph as pages: entities, relations and observations that strains read and write through MCP rather than re-deriving each session. This is the mycelium — the part that means a new strain starts informed instead of starting over.
A reader over the object store: files a strain wrote, artefacts a job produced, the raw material under the git objects. Everything in the lake is encrypted at rest in a PCV1 envelope, with the AAD binding the full GCS object key so two identically-pathed repos cannot collide.
Append-only. Who staged a job, the exact command, what it returned. Auto-approve does not remove the record — it removes the tap. If you want to know what your fleet did last Tuesday, this is the page that answers, and it answers with commands rather than summaries.
Not a console page — the second Cloud Run surface, for machines. Same image, different
service, split by a 90-entry route table enforced at build time. IAP consumes the
Authorization header, so an MCP client can never live behind IAP. That is
why there are two services.
Both surfaces come out of one container image. A route that lands on neither service throws at boot rather than 404-ing in production, and SDK v2 loadability is asserted at boot and deliberately left uncaught — a broken dependency fails the container, so Cloud Run keeps serving the last good revision instead of routing traffic to a green box that is missing a capability.
Honest reading
A demo that only tells you what it is good at is an advert. Here is the boundary.
They do not prove your build will succeed first time.
A strain writing a container that builds cleanly is normal; a strain writing one that fails on a missing base image is also normal. What the product guarantees is that you see which stage failed and what it printed, and that the attempt is journalled either way.
They do not prove anything about scale.
These are single-service deploys in one project. We do not publish benchmarks, and we are not going to invent one here. What we will say precisely: Cloud Run scales to zero, and so does the git store, because there is no server and no clone and no disk holding it open.
They do not show a human approving each command.
Correct, and deliberately so. That affordance does not exist in this product. A tap in front of every command does not make a system safer — it makes it slower and teaches everyone to click through. The controls that do the work here are identity scoping, a signed and pinned command digest, one-time claim on the executor, and a journal you can read afterwards.
They are not a substitute for reading the source.
Apache-2.0, whole tree, including the executor that holds only the public half of the signing key and verifies a signature it could not produce. If a claim on this site matters to your decision, the file that implements it ships with the release.
Try it here
Two demo affordances run on this site. Both are metered: they draw on a fixed monthly minute budget that we pay for, and when the budget is spent for the month they stop until it resets. That is the honest description — not a trial, not a queue, a capped meter.
Checking how many demo minutes are left…
The support agent answers questions about the harness from the same MCP surface your own install exposes. The avatar is a video front end on top of it. Neither one has any access to your Google Cloud project, and neither one is required to install or run anything on this site.
Next
One command, no arguments, a GCP project with billing enabled. The console URL and the MCP URL are printed at the end.