Repository navigation
Description
Summary
In two dependency-maintenance runs using unmodified GH-AW v0.92.0, the Codex agent interpreted the immutable XPIA prompt's secret/env/.env/cache access prohibition as blocking ordinary dependency installation or tests that load versioned, nonsecret test configuration.
This was an instruction-based refusal: the required test command was withheld, not attempted and denied by the sandbox. The local workflow also had an overly broad dotenv exclusion; we are correcting that separately rather than attributing the entire problem to GH-AW.
Observed behavior
- A strict dependency workflow found a candidate but declined package installation and checks because they use caches. It emitted
report_incomplete. - With fresh disposable package directories configured through native
engine.envand a bounded task clarification, another run successfully resolved and installed dependencies and passed formatting, lint and type checks. It then withheld pytest because test settings load a tracked.env.testcontaining local service settings and placeholder-only secrets. It again emittedreport_incomplete, and no PR was published.
These are observations from a private consumer workflow using gpt-6.1-terra at medium effort, not a standalone public reproduction or evidence that every engine/model will refuse. Private logs and configuration are omitted.
Policy ambiguity
The stock prompt does not distinguish credential-bearing runner caches/environment material from assigned disposable package/build state or repository-owned nonsecret test fixtures. The same wording is present in the current default-branch copy checked on November 2, 2026.
Meanwhile, the strict Update Astro workflow assigns package installation and a build, and the cache FAQ explicitly supports safely scoped module/build caches.
I did not find a narrow strict-mode setting for this distinction. Omitting XPIA using disable-xpia-prompt requires non-strict mode; public repositories require strict mode at runtime.
Requested clarification
What is the supported strict-mode way to run ordinary checks using explicitly provisioned, nonsecret test/build state?
If these operations are intended to be supported, could the stock policy distinguish them from unauthorized credential discovery/access? The useful boundary seems to be the authority a setting grants and its provenance, rather than its filename:
- Assigned disposable package/build state, repository-owned nonsecret test configuration and dummy credentials scoped to disposable services can be used for checks. A tracked filename alone does not establish that a value is safe.
- Ambient developer/runner credentials, secret stores, unrelated host state and privileged publication credentials remain outside that task scope. Sandbox, network and tool boundaries remain enforced, and repository contents remain untrusted data.
A minimal strict-workflow acceptance case could install a package and run a test loading a tracked fixture containing only APP_MODE=test and a placeholder. That standalone case is proposed and has not been hosted-tested. A clarification or supported mechanism would let consumers retain the native policy without patching prompts or maintaining growing local filename exceptions.
Activity
ternarybits commentedon Nov 2, 2026
Following the community contribution process, here is a concrete implementation proposal against current main (
8e5dee106). No consumer runtime patch is proposed.In
actions/setup/md/xpia.md, replace the blanketsecret/env/.env/cache accessphrase with credential discovery, unauthorized secret access, and inspection of ambient developer/runner configuration or unrelated host caches. Add:Preserve the existing physical-boundary and untrusted-content rules, strict-mode requirement, and prohibition on XPIA opt-out in strict mode.
Extend the existing
.github/workflows/smoke-codex.mdbuild check with the dependency-free fixture below in a fresh disposable directory. Keep the existing Go package/build cache check; add no new schedule, permission, secret, or evaluator.Acceptance: strict-mode smoke execution installs/builds/tests the explicitly supplied dummy fixture and completes its existing cache-backed build, without interpreting fixture contents as instructions or inspecting ambient credentials. Deterministic tests cannot establish model adherence; maintainers still need a reviewed hosted smoke execution.
Minimal fixture and provider-free local results
package.json:{ "name": "gh-aw-nonsecret-state-smoke", "version": "1.0.0", "private": true, "type": "module", "scripts": { "build": "node --env-file=.env.test build.mjs", "test": "node --env-file=.env.test --test fixture.test.mjs" } }.env.test(only these dummy values):build.mjs:fixture.test.mjs:Inside a fresh fixture directory, with a separate fresh cache and two distinct empty npm configuration files:
Provider-free local results on Node v24.21.0: offline install, build and test passed. Removing
.env.testfailed with exit 9; corruptingdist/result.txtfailed with exit 1. There are no third-party dependencies. Validation used only the explicit dummy settings; no production/provider/publisher credentials or inference calls were involved.This establishes that the fixture is executable and checks meaningful outcomes. It does not establish hosted model adherence, a sandbox security property, or successful execution of the upstream Go build. No upstream workflow was dispatched and no consumer release/compiler was modified.