admin@company.com exists in FlareID but is not an employee in any of the apps, and every MCP server maps the Access identity to an employee record before it will issue a token.

A local VM or a cloud one, either is fine — but do use one. This is the recommendation that saves the most grief, and the reason is not tidiness.

Enrolling a device in this demo's Zero Trust organisation is not a small act. wire-access.sh deliberately turns on install CA to system certificate store, because Gateway cannot inspect HTTPS unless the device trusts its certificate — so the Cloudflare One client puts this tenant's root certificate into your trust store, and from then on the demo account can decrypt that device's traffic. On a disposable VM that is exactly what you want. On your work laptop you have handed a demo tenant your browsing.

Three more reasons, each of which costs an afternoon the first time:

• The DLP policies apply to everything the device does, not just the demo. The rule that blocks a paste into Gemini does not know which browser tab is yours. Your own AI tooling stops working while you are enrolled.
• You have to be Alice. The device session is the credential for the model endpoint, so the client has to be signed in as alice.watson@company.com — which is not a thing you want your real machine to be.
• Resetting between runs is a snapshot rather than an archaeology exercise. Client config, MCP OAuth tokens and chat history all accumulate, and a stale portal registration fails in a way that does not look like auth. A VM you can roll back makes that a non-problem.

A cloud VM has one extra advantage worth knowing: you can hand the whole thing to a customer or a colleague to drive, which is the difference between showing a demo and running a lab.

Cloudflare OS is the exception and needs none of this — it runs in a browser and authenticates through Access, so there is no device to enrol and no certificate to install. If you cannot make a VM, that is the client to use.

Read this before choosing opencode, because it costs you something in every step that matters. When the gateway refuses a call, opencode reports the whole of it as:

Provider request failed with HTTP 424

No reason, no policy name, nothing to read out. The gateway does send one — "Request content blocked due to DLP policy violations" — and opencode discards it. Goose prints it:

Request failed with status 424 Failed Dependency at
https://aig.<your-zone>/compat/v1/chat/completions:
Request content blocked due to DLP policy violations.

Six of the walkthrough's eight steps end in something being refused, so this is not a rough edge in a corner — it is most of what the room sees. On opencode every one of those becomes you switching to the AI Gateway dashboard to explain what just happened, which works but turns a thirty-second beat into a two-minute one and moves the audience's attention off the transcript.

Nothing here is fixable from our side: the gateway sends the reason, the client drops it. If you are already set up on opencode it is perfectly usable, and the walkthrough tells you where to look for each block. If you are choosing now, choose Goose.

opencode runs on your machine, and that machine has to be enrolled in the Cloudflare One client and authenticated as alice.watson@company.com. Not optional, and not just for tidiness — it is what makes the configuration below work at all.

The device session is the credential. The Access application in front of is configured to accept it, which is why the provider config has no API key in it: nothing in a file, nothing in an environment variable, nothing on disk. Without the client, every model call is turned away by Access before it reaches the gateway.

Signed in as the wrong person is worse than not signed in, because it looks like it works: the requests succeed and every one of them is attributed to whoever that is. The walkthrough's argument is that the agent acts with Alice's identity, so check the client's account before you present, not after.

The same session is what makes step 1 happen: the browser-side DLP policy and the desktop notification explaining the block both come from this client. On a machine without it, cloudflared can fetch a short-lived Access token instead, and opencode can run that for you — but you lose step 1, so for a demo it is not a real substitute.

One deploy-time caveat, because it fails the same way as a missing client. Accepting a device session needs an account-wide Cloudflare One Client Authentication duration to exist first, and wire-access.sh degrades rather than failing if it cannot set one — it prints "Without client-session auth: clients authenticate with 'cloudflared access login' instead". If you saw that, the flag is not on the application and no device session will authenticate, however correctly the client is signed in. Turn it on under Zero Trust → Access controls → Access settings and re-run.

Cloudflare OS needs none of this: it authenticates in the browser, so a signed-in Access session in any tab is enough.

Verified on opencode Desktop 2.0.22: the 1.x configuration works and the 2.x one does not. The desktop app's version number is its own, and it does not tell you which config schema it reads — a "2.0.x" desktop build still wants the 1.x shape.

So: Desktop → the 1.x card. Reach for the 2.x card only if you are running the 2.x CLI, where opencode --version does mean what it looks like:

opencode --version

Getting this wrong is quiet, which is why it is worth stating. 1.x accepts keys it does not understand without complaining, so a 2.x config on a 1.x-shaped client validates, loads, and does nothing: the agents block with its permissions, system prompt and step cap is read and discarded. The first you know of it is an agent spending seventeen steps guessing at tool names in front of an audience.

The one error it does raise is the good case, and worth memorising:

Configuration is invalid at ~/.config/opencode/opencode.json
  V2 permissions are not supported by OpenCode V1.
  Use V1 "permission" rules or run opencode2.   agents.employee.permissions

Either way, confirm rather than assume: opencode agent list should show employee with "permission": "execute" denied. And during a run, a single Execute row in the transcript means the deny is not in force — nothing else needs checking first.

This is the one that makes everything else look broken, and no prompt or instruction fixes it. A granted MCP resource becomes a binding in the chat where you granted it. A new chat is seeded from gadgets and nothing else, so it starts with no portal binding at all — and the agent has no choice but to ask for one again, which is most of the steps you were trying to avoid.

So the pre-grant is not a global setting you do once. Open the chat you are going to demo in, grant WorkBox and Pipeline there, and run all eight steps in that same chat. Switching chats between steps puts you back to an eight-step step 4.

A tell-tale: a grant you made yourself from the composer is named after the system — WORKBOX_MCP — and one the agent requested is named whatever the agent chose, so COMPANY_PORTAL or COMPANY_AI_PORTAL. If you see the latter, the chat had no grant and the agent asked for one. A name that changes between runs means a new grant each time.

If you will run this more than once, there is a way out of the per-chat grant. A chat's starting bindings come from the workspace's gadgets, so a gadget holding the portal bindings seeds every chat after it. cloudflare-os-instructions.md has the recipe — grant the servers, ask the agent to create a holder gadget and wire them in with setGadgetBinding, then accept the changes, which is the step that makes it permanent.

Two caveats. It is per workspace, so per person, like the model. And it is an off-label use: setGadgetBinding says to use it only when a gadget's code needs the resource, whereas we want the propagation side effect — which rests on how defaultBindingList reads gadget bindings, an implementation detail rather than a contract. Good enough for a demo; worth knowing before building a workshop on it.

If you skip the grants and let the agent ask mid-chat, it calls requestConnection and you get an accept card. Accept it and the grant is made — but the server it ends up scoped to may not be the one the card describes. A card reading "I need access to the Company AI Portal to search the WorkBox calendar" has been observed producing a binding onto Nexus, the wiki.

That failure is expensive and does not look like a failure. The agent holds a binding it believes is the calendar, so it writes code against it, finds nothing, assumes it searched wrong, and tries again — eight or ten executeCode runs, no answer, and a room watching a progress spinner. Nothing in the transcript says "wrong system".

How to check in two seconds: every code row names the server it read, after the portal's name — Company AI Portal / Nexus MCP. If that is not the app your prompt named, the binding is wrong and no amount of waiting will fix it. Grant the right server from the composer, where you pick it yourself.

Which is the real reason to grant before you start, rather than politeness about not interrupting the demo.

Skip that and the agent meets the portal for the first time mid-demo. It has no connection, so it reasons about that at length, calls listConnectableResources, and asks you to set one up — interesting once, and a poor way to open a walkthrough whose argument depends on the tools being unremarkable.