Setting up the agent

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. Authenticate as admin and the flow dies at the token exchange with a generic "Failed to retrieve authentication tokens" — the useful message ("no matching active employee was found") is produced by the MCP server but never surfaced.

There is a second reason to use the demo persona. Whoever you authenticate as becomes that server's admin credential, which is what the portal falls back to if Require user auth is ever turned off. Using the lowest-privileged person in the company means that misconfiguration fails safe, instead of silently granting every portal user the session of whoever happened to set it up.

1.x accepts keys it does not understand without complaining. A 2.x config on 1.x therefore looks completely fine and does nothing: an agents block with its permissions, its system prompt and its step cap is read, validated and discarded. The first you know about it is an agent spending seventeen steps guessing at tool names in front of an audience.

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

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

If you see that, you are on 1.x with the 2.x config. Open the first card below.

Both configs carry "codemode": false on the server and a denial of execute. They are a pair, and half of the pair is worse than neither.

opencode puts MCP servers behind Code Mode by default. In that mode the model does not receive the portal's tools as functions it can call; it gets a JavaScript sandbox and has to discover them through a search() helper. With five servers and forty-odd tools the catalogue it is shown is partial, so it must search - and the form models reach for, tools.search({ ... }), is not the one that works.

"codemode": false moves the tools onto the native tool list, where the model can simply call the right one. But it also moves them out of the sandbox catalogue, and the execute tool is an opencode built-in that does not disappear along with them. Leave execute available and you have given the model two doors, one of which cannot possibly work:

Used 17 Execute
  await tools.ai_demo_work_list_company_calendar({...})   <- Unknown tool
  await tools['ai-demo_work_list_company_calendar']({...}) <- Unknown tool
  await tools.search({ query: 'calendar' })               <- finds nothing
  return Object.keys(tools);                              <- the MCP tools are not in there
  ... fourteen more ...
Called `ai-demo_work_list_company_calendar`               <- and finally, natively

Denying execute removes the second door. The same prompt then reads:

Used 2 ai-demo_work_list_company_calendar
  Called `ai-demo_work_list_company_calendar`  acquisition  from=... to=...
  Called `ai-demo_work_list_company_calendar`  restructure  from=... to=...

The test, in one line: if there is a single Execute row in the transcript, the deny is not in force. Nothing else about the run needs checking first.

There is a second reason to turn it off, and it matters more than the speed. Code Mode exists to let an agent combine tools "without adding every intermediate value to the model context" - in other words, a tool result can be processed inside the sandbox and never appear in the conversation.

This entire demo depends on the audience seeing the over-shared data land in the transcript. A run where the agent quietly reads the whole company calendar inside a sandbox and summarises it in one line proves the same thing technically and nothing at all on stage. The Gateway logs are identical either way; the screen is not.

opencode is a coding agent: out of the box it has a shell, a file reader and a web search, and it is running inside a project directory. Ask it What is Nikita Chapman's home address? with those available and it will cheerfully grep your filesystem and search the web — six tool calls, no MCP, and a demo that proves nothing. That is what the rest of the deny list is for: with every built-in refused, the company's MCP tools are the only way to answer anything.

opencode speaks Streamable HTTP MCP directly and runs the OAuth flow itself — it sees the portal's 401, follows the resource_metadata hint, registers itself dynamically and stores the token. So there is no mcp-remote and no subprocess.

The older {"type": "local", "command": ["npx", "-y", "mcp-remote@latest", ...]} recipe works from a terminal but fails in the desktop app with NotFound: ChildProcess.spawn, because a GUI application does not inherit your shell's PATH and npx usually lives somewhere like /opt/homebrew/bin. If you do want that form, give the absolute path to npx.

There is a security reason too. mcp-remote carried CVE-2025-6514, a critical command-injection flaw triggered by connecting to a malicious MCP server, fixed in 0.1.16. Cloudflare's own docs recommended it widely at the time. Not connecting through it at all is the simpler answer — and see the real incidents page for why this whole layer deserves the scrutiny.

cloudflare-ai-gateway is a real provider id in models.dev, with a catalogue of the 47 third-party models AI Gateway can proxy. Name your provider that and opencode matches it by id, merges that catalogue, and ignores the models map you wrote: the picker fills up with Claude, GPT and Qwen entries, and the app starts probing models you have no provider keys for. Any id that isn't in models.dev - cf-ai-demo here - avoids it. Restart opencode after editing, since it caches the catalogue.