[BUG] Free models fail when `shell` or `read` permissions are denied

[Otagamo]

Description

Free models fail when shell or read permissions are denied

Description

Using OpenCode v2.0.16 with OpenCode free models such as opencode/big-pickle.

If either the shell or read permission is set to deny, requests to free models fail with:

Error: OpenCode's free tier can only be used from within OpenCode

For example:

{
  "action": "shell",
  "resource": "*",
  "effect": "deny"
},
{
  "action": "read",
  "resource": "*",
  "effect": "deny"
}

Changing both permissions to allow immediately makes the error disappear:

{
  "action": "shell",
  "resource": "*",
  "effect": "allow"
},
{
  "action": "read",
  "resource": "*",
  "effect": "allow"
}

The behavior can be reproduced without restarting OpenCode: changing these permissions while OpenCode is running changes whether the next request succeeds or fails.

Expected behavior

Tool permissions should control whether the model can use those tools.

Denying shell or read should not cause a request made from the official OpenCode CLI to be identified as coming from outside OpenCode.

Actual behavior

Disabling these tools causes OpenCode free-tier requests to be rejected as if the request were not originating from OpenCode.

Environment

• OpenCode: v2.0.16

Plugins

Reproduced with the official CLI. The behavior is permission-dependent.

OpenCode version

2.0.16

Steps to reproduce

1. Run OpenCode v2.0.16.
2. Select a free OpenCode model, for example opencode/big-pickle.
3. Set shell or read to deny.
4. Start a new session or send a simple prompt such as Hello.
5. The request fails with:

Error: OpenCode's free tier can only be used from within OpenCode

6. Change both shell and read to allow.
7. Send the same prompt again.
8. The request succeeds.

Screenshot and/or share link

No response

Operating System

Windows 11 25H2 26200.9457

Terminal

PowerShell 7.6.6.0-x64

[holny]

I'll take this. Denying shell or read shouldn't trip the free-tier provenance check — those two sounds like they feed the same environment/header path that proves the request came from OpenCode, so a deny probably short-circuits something that looks like client identity to the gateway.

I'll trace where a denied shell/read permission changes what the CLI sends (headers or body) on free-tier requests, fix it so permissions only affect tool availability, and add a regression test that runs with both denied and asserts the request still goes out as an official client.

Fixes #51241

[holny]

Update after digging: I couldn't find any client path where a denied shell/read permission changes what the CLI sends — the free-tier provenance check is enforced by the Zen gateway against the config the CLI pulls from the console (plugin/provider/opencode.ts builds its headers from that remote config, independent of tool permissions). I also can't reproduce the gateway's decision locally without a free-tier credential, so I'm stepping back from this one rather than guess at a client fix. Gateway-side investigation (why a denied tool flips provenance) is probably where this lands.

[Mike-Rice]

Confirming on opencode 1.18.33 (V1), built-in opencode provider, opencode/big-pickle, empty project:

• permission.bash: "deny" → Error: OpenCode's free tier can only be used from within OpenCode
• permission.bash: "ask" → works
• tools.bash: false also reproduces

Root cause is the absent bash tool in the outgoing request (see #50627 and #51315). ask (or allow) is the workaround.

[Dioarya]

Repro'd on Windows with scoop install main/opencode, opencode version 1.18.34, empty project.
C:\Users\<User>\.config\opencode\opencode.jsonc

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "*": "deny"
  }
}

and

{
  "$schema": "https://opencode.ai/config.json",
  "permission": "deny"
}