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.

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.