Full auto: every tool is allowed, by the catch-all the product documents -- and the honest half of that sentence is that this build already allows every tool without it. Measured against the pinned 1.18.25 bundle with debug agent build…

[Catalog](/en/ai/catalog)

[Publisher](/en/ai/publishers/account_01KZET6ZKJN7S72T5H4WDV62T0)

- stable_id: setup_01M18ZSX65Z6QKSCCXJHYDAQ4K

- version: 1.2

- digest: sha256:74d25c831be8b4b69aaa4defb914048deb03b36d6f9db8b02bb5d70571ed8f5c

- harness: opencode

- Purpose: Full auto: every tool is allowed, by the catch-all the product documents -- and the honest half of that sentence is that this build already allows every tool without it. Measured against the pinned 1.18.25 bundle with `debug agent build` under a temporary home. The product decides by the **last** matching rule -- the shipped binary selects with `findLast` -- and a configured permission map is appended *after* the product's own rules rather than before them. With no configuration the resolved list for the default agent opens `* -> allow`, then `doom_loop` and `external_directory` ask, `question`, `plan_enter` and `plan_exit` deny, and `read` asks for `*.env` and `*.env.*` while allowing `*.env.example`. Writing `permission: {"*": "allow"}` puts a second `* -> allow` after every one of them, and under last-match-wins that copy is the one that decides: those prompts and denials do not happen. Naming the seven explicitly moves them the same way -- each appears again at the end carrying the action you wrote. So this file does not restate the product's own opening `* -> allow`: same rule text, opposite power, because position is the semantics here. The product's copy is first and therefore the weakest thing in the list; this one is last and therefore the strongest. **This description said the reverse until 2026-08-31**, that the seven were the product's own and no configuration moved them. The measurement behind that sentence asked whether the seven were still in the resolved list -- they are, every one, and they are still printed there -- instead of asking which row decides. Presence is not precedence, and a rule you can still see is not a rule that still governs. This build also reads no capability toggle beyond the permission map: `autoupdate`, `share`, `snapshot`, `watcher`, `experimental`, `instructions`, `formatter`, `lsp`, `small_model` and `disabled_providers` are the other keys it accepts, and `attribution`, `tui`, `keybinds`, `theme`, `reasoningEffort` and `textVerbosity` are dropped exactly as an invented key is -- which is how the first list was told from the second. `autoupdate` is deliberately not set on either side: this provider pins the version it installs, and a product that updates itself would move the bytes out from under the record of what was installed. That reason stood for three releases with nothing enforcing it. Provider launch now sets `OPENCODE_DISABLE_AUTOUPDATE=1`, which the pinned build reads as an unconditional gate on the automatic path; the configuration key is the alternative in the same condition and this provider's target is not where that key is read from. Neither stops a person typing `opencode upgrade`. `share` sends something outward rather than granting you a tool. This product documents no sandbox to turn off. This is a setup posture -- keys in this product's own configuration file. It is not an execution profile and it grants no environment: what it changes is what the product asks you, not what anyone is permitted to run. The key measurement behind this posture: `debug config` and `debug agent build` against the pinned 1.18.25 bundle under a temporary home, with an invented key as the control.

- Target role:

- posture: full-auto

- trust_lane: authoritative

- author_verified: Yes

- component_verified: Yes

- Lifecycle: active

- Author: account_01KZET6ZKJN7S72T5H4WDV62T0

- Tags: code-review, devops, planning

- install: ai-stp registry version --kind setup --id setup_01M18ZSX65Z6QKSCCXJHYDAQ4K --version 1.2