Verify and operate
OpenCode and Pi activate independently through their package entries, source loader files, and host-owned policy paths. Removing one installation leaves the other host unchanged. After upgrading from 0.2.0, verify migration before removing the shared legacy file.
Verify OpenCode
Section titled “Verify OpenCode”After installing the plugin, inspect the resolved configuration:
opencode debug configThe resolved plugin list must contain the Auto Mode Gate entry. This confirms discovery only;
it does not prove that the hook ran. Restart OpenCode after configuration changes.
From a source checkout, the black-box host integration packs the current candidate, installs it
under a temporary root, and runs OpenCode 1.18.18 twice against a loopback provider. The control
must create a marker; the protected run must return AMG_DENY_AMBIGUOUS without creating it:
npm run test:opencode-hostThe reproducible gate runs on Linux CI and exits on Windows; the historical Windows host probe remains separate evidence. The integration uses no real credentials or external model inference and does not read or modify the active OpenCode profile. CI installs the pinned host from npm, and OpenCode may resolve bundled plugin/provider dependencies during setup; the configured model endpoint is loopback.
Verify Pi
Section titled “Verify Pi”After installing the package, inspect the installed package list:
pi listPi lists installed packages in pi list; it does not list auto-discovered extension files there. A source installation can be checked without contacting model providers:
pi --offline --list-modelsVersion 0.4.3 retains the Pi 0.84.2 requirement for persistent controls introduced in 0.4.0. Verify requested and effective state with:
/amg-judge statusRun /amg-judge without arguments in TUI mode to open the control menu. Direct on, off, model, thinking, and reset commands save the global preference snapshot before changing the current session. They never change Pi’s primary model or thinking. Read Use Pi judge controls for the full command, shortcut, persistence, and failure behavior.
What is enforced
Section titled “What is enforced”Both adapters enforce calls to their built-in bash tool. Other tools remain under native host permissions. The shared conformance suite exercises deterministic and judge outcomes. Pi can judge an eligible request in an active session; OpenCode blocks the same case as unavailable.
A child process must load its own adapter. The hooks do not guarantee that a separately launched child host loaded the gate.
What happens after an allowance
Section titled “What happens after an allowance”An allowance means that the Auto Mode Gate policy did not block the call. Native OpenCode or Pi permissions still apply after that decision. Passing the gate does not bypass or replace host permissions.
Verify configuration isolation
Section titled “Verify configuration isolation”OpenCode must ignore Pi’s global and .pi project destinations. Pi must ignore OpenCode’s global and .opencode destinations. An existing host-owned file also suppresses legacy discovery for that host. Test changes with harmless policy settings and restart or reload the relevant host.
Useful checks
Section titled “Useful checks”Run the project test suite and, when the pinned host is available, the OpenCode integration from the repository root:
npm testnpm run test:opencode-hostThe published package documents only the validated OpenCode, Pi, and Node baselines. Version 0.4.3 retains the persistent controls and explicit secondary-model thinking on Pi 0.84.2 introduced in 0.4.0, but no real-model inference was used for validation. Do not infer broader compatibility or provider safety from a successful local or loopback run.