agent-task OpenCode runner preflight should validate model, auth, and workspace permissions

[chubes4]

Problem

Lab OpenCode readiness failures are discovered only after fanout handoff, and the resulting errors are hard to connect to a concrete remediation.

Evidence

Observed during figma-scale-lab-wave-20260707:

• Bare model gpt-5.5 resolved as gpt-5.5/. and failed with ProviderModelNotFoundError: Model not found: gpt-5.5/..
• Fully-qualified openai/gpt-5.5 then exposed stale Lab auth: Token refresh failed: 401.
• After auth refresh, fanout reached OpenCode but failed on workspace access policy: permission requested: external_directory; OpenCode permission policy denied tool call glob.
• Manual runner config changes were required before the same executor could run.

Expected

Homeboy's OpenCode runner readiness/preflight should verify before dispatch:

• the selected model is fully-qualified or resolves to an available OpenCode provider/model,
• OpenCode auth can refresh or run a trivial request,
• workspace paths that Homeboy will hand to OpenCode are allowed by OpenCode permissions,
• glob and expected workspace tools are allowed.

Why it matters

These are deterministic runner readiness issues. Detecting them before fanout avoids burning every child attempt on the same environmental failure.

[chubes4]

Reproduced again on the accepted 9c88ee2ce072 controller while continuing the gate-feedback lifecycle for Automattic/wp-codebox#1825.

Run: wp-codebox-1825-gate-fix-2c

Homeboy successfully verified the complete promoted-candidate baseline and materialized the retry at:

~/.local/share/homeboy/controller-scratch/attempts/wp-codebox-1825-gate-fix-2c/wp-codebox-1825-gate-fix-2c/cook-wp-codebox-gate-fix-2/attempt-1/<attempt>/workspace

The OpenCode executor then auto-rejected its first read-only grep against that exact Homeboy-owned workspace as external_directory, producing opencode.policy_denied, an empty patch, and an exhausted provider execution. glob happened to run, while grep was denied, so the effective permission contract is also inconsistent across workspace read tools.

Concrete acceptance addition: execute a real gate-feedback retry through the OpenCode adapter, assert every generated attempt workspace is present in the executor permission policy, and prove grep, glob, read, and patch/write calls can operate there without permission prompts. This must cover controller-scratch paths, not only the original managed worktree.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.6 Sol), Homeboy
• Used for: Reproducing the gate-feedback failure, inspecting durable executor evidence, and drafting this evidence update.

[chubes4]

Ownership follow-up from the recovery worktree: Homeboy core correctly remaps the concrete attempt workspace before dispatch (attempt_workspace.rs / scheduler engine). The missing permission is in the OpenCode adapter owned by Extra-Chill/homeboy-extensions: agent-runtimes/opencode/lib/opencode-agent-task-executor.js generates OpenCode config without allowing the concrete request workspace under permission.external_directory. I am moving the implementation to that owning repository; Homeboy #7720 remains the cross-layer readiness tracker.

[chubes4]

Post-merge verification of Homeboy Extensions #2282 isolates the remaining behavior. Runtime revision e64b8e27 was installed and the assigned-workspace rule worked: read succeeded against the exact materialized path under .../wp-codebox-1825-gate-fix-2e/wp-codebox-1825-gate-fix-2e/.../workspace/tests/.... The denied grep and first read targeted a different sibling path missing the run-id suffix (.../wp-codebox-1825-gate-fix-2/...), which correctly remained denied.

Homeboy nevertheless classified the entire provider outcome as opencode.policy_denied and discarded it after any rejected tool call appeared in the transcript. The permission-boundary fix is therefore behaving correctly; remaining recovery needs to distinguish a terminal provider permission failure from an individual denied tool call that the agent can recover from. Do not broaden the path allowlist to cover typo/stale sibling attempts.

[chubes4]

Reproduced the remaining false-terminal behavior again while continuing Automattic/wp-codebox#1838.

Run agent-task-da36674c-ad40-4cbe-9669-a240ff411f22 used the accepted homeboy 0.291.5+113fd932f0b8 controller. OpenCode successfully ran glob against the exact assigned attempt workspace. Its next grep contained a mistyped plan UUID segment, so the adapter correctly denied that sibling path as external_directory. Homeboy then classified the whole provider outcome as opencode.policy_denied, emitted an empty patch, exhausted the execution budget, and prevented the agent from correcting its typo.

This confirms the current permission allowlist is working and should not be broadened. The remaining fix is the issue’s existing acceptance requirement: distinguish a denied individual tool call from a terminal provider permission failure, allowing the OpenCode session to continue and recover when the CLI remains healthy.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode (GPT-5.6 Sol), Homeboy
• Used for: Reproducing the failure, inspecting durable executor evidence, and drafting this evidence update.

[chubes4]

Owning-layer repair is ready in Extra-Chill/homeboy-extensions#2300. It preserves status-0 OpenCode success after an individual denied tool call while retaining policy_denied for genuine nonzero terminal failures. Focused adapter boundary tests and runtime-manifest validation pass.

The dependent WP Codebox candidate is prepared but intentionally remains blocked on WordPress/wordpress-playground#4110 rather than reintroducing a full-archive ZIP fetch.

[chubes4]

The owning-layer repair has merged in Extra-Chill/homeboy-extensions#2300 as 5800228ad589f93305043b3bf9b495538a2441ba. The local OpenCode extension and shared runtime package were refreshed from the accepted change; the installed adapter boundary test and runtime-manifest check both pass.

The original WP Codebox task now proceeds only after the upstream Range ZIP prerequisite WordPress/wordpress-playground#4110 is accepted. No full-archive fallback was introduced.

[chubes4]

Post-install lifecycle proof: cook agent-task-930535dd-b517-42f4-96b1-81f3ddc62eb2 deliberately triggered an external-directory denial and allowed two provider executions. Both were classified candidate_recoverable with no policy_denied failure, and Homeboy queued/performed the configured retry. The synthetic prompt deliberately repeated the denied call on each retry, so it ended at the normal no-actionable-patch gate rather than producing a candidate. This confirms homeboy-extensions#2300 removes the false terminal provider-policy classification and restores retry lifecycle ownership.

[chubes4]

Fresh evidence from cleanup-ux-9823-9826-20260723 on 2026-07-23:

• cook-batch --backend opencode --selector opencode.agent-task-executor --model gpt-5.6-sol passed Homeboy readiness but all four children failed immediately with OpenCode Unexpected server error refs such as err_8025db1e.
• The normalized failure only said OpenCode CLI exited with status 1; it did not identify model normalization as the actionable boundary.
• Retrying the same preserved worktree with --model openai/gpt-5.6-sol reached OpenCode successfully and produced a non-empty candidate patch.

This confirms the preflight still accepts a bare model that the runtime cannot execute and turns one deterministic configuration error into four burned child attempts.

AI assistance: OpenAI GPT-5.6 Sol via OpenCode/Kimaki was used to execute the batch and capture this evidence.

[chubes4]

Fresh 2026-08-02 evidence across five Cooks: OpenCode denied expected coding tools (glob, read, bash, and grep) while the CLI process exited 0. Homeboy then persisted empty patches, missing review_form, recoverable/partial outcomes, and consumed retries without useful work. Representative runs include agent-task-d32a0ced…, agent-task-bc161c88…, agent-task-c8b92e27…, agent-task-78c968c0…, and agent-task-9601ea53….

This reinforces both remaining contracts already discussed here: preflight the concrete assigned workspace with the actual standard tool set, and distinguish a recoverable individual denial from terminal permission failure. Compact outcome should name the denied tool/path rather than lead with OpenCode CLI exited with status 0.

AI assistance: OpenAI gpt-5.6-sol via OpenCode reviewed durable Cook aggregates and transcripts, correlated denied tools across runs, mapped the evidence to this tracker, and drafted this update. Chris Huber remains responsible for the report.