ℹ️ About Codex in GitHub

\\n
\\n\\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\\n- Open a pull request for review\\n- Mark a draft as ready\\n- Comment \\\"@codex review\\\".\\n\\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\\n\\n\\n\\n\\nCodex can also answer questions or update the PR. Try commenting \\\"@codex address that feedback\\\".\\n \\n

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Require successful results for skill and tool checks**\\n\\nWhen `load_skill` or another required tool is rejected or fails, these checks still pass solely because a matching `tool_call` exists. Although the updated `toolRequests` path now correlates calls with successful results, this fresh evidence shows the `skills` and `tools` loops still do not, so the signup smoke test can report that both skills were loaded and required instrumentation was exercised even when their results have `success: false`; correlate these checks with their `tool_result` records as well.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"ci/lib/grader.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Remove capability URLs from sensitive artifacts**\\n\\nFor the sensitive Gnippets scenario, `final_url` is the high-entropy fixture capability URL derived from `setup.app_url`, but both this sanitizer and `sanitizeRun` retain it verbatim. If fixture deletion fails, the workflow still uploads artifacts via its `if: always()` step, exposing a live bearer-style URL until expiration despite the sensitive-artifact policy; omit the URL or retain only non-capability origin information.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"ci/lib/sanitize.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `cd80970f2b`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Allow the serial smoke pack to reach its configured timeouts**\\n\\nWith the workflow running `cloud-smoke` at concurrency 1, the four scenarios allow 50 minutes of agent execution alone, because the Wikipedia and NYTimes scenarios each perform a preload run with the same timeout before their main run; `waitForRun` also adds two-minute buffers and browser provisioning and tests consume additional time. When multiple external sites are slow but still within their scenario budgets, this 45-minute job limit terminates Node before it can write the suite report or execute the browser/fixture cleanup in `finally`, so increase the job timeout or run scenarios concurrently.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\".github/workflows/webbrain-cloud-smoke.yml\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Trigger the smoke workflow for cloud bridge changes**\\n\\nThe changed `src/chrome/src/offscreen/cloud-bridge.js` controls the cloud handshake and now advertises `run_modes_v1`, but none of these push-path entries covers that file. A future bridge-only change can therefore land on `main` without immediately running the cloud smoke pack that depends on the bridge, leaving failures undiscovered until the next scheduled run; include the offscreen bridge path in this filter.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\".github/workflows/webbrain-cloud-smoke.yml\",\"side\":\"RIGHT\",\"line\":16}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `7885329a55`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Validate scheduled job targets and prompts**\\n\\nFor the Google Forms smoke scenario, these checks accept any two `schedule_task` calls whose jobs later report `completed`/`success`; they never verify the requested Forms URL, the 0/60-second schedules, the distinct A/B prompts, or that the returned IDs match the result fields. A run can therefore pass after scheduling two unrelated successful jobs without exercising either form submission, so retain and grade the scheduled job definitions or the corresponding call arguments.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"ci/catalog/scenarios.json\",\"side\":\"RIGHT\",\"line\":391}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the scheduled-wait failure stage**\\n\\nWhen the main Google Forms run succeeds but either scheduled job remains nonterminal past `scheduled_timeout_ms`, this rethrow reaches the outer catch and is assigned to `setupError`; `inferStuckAt` then unconditionally reports `setup`. The smoke summary consequently attributes a post-run scheduled-execution timeout to fixture setup, obscuring the actual failure stage; track this error separately as scheduled execution or verification.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"ci/run.mjs\",\"side\":\"RIGHT\",\"line\":272}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `c53cb8c5cd`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `56e9b3e21b`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact verify_form results in strict cloud runs**\\n\\nWhen a strict-secret cloud run calls `verify_form`, only `fetch_url` results are sanitized here, so the result falls through unchanged. The top-frame `verify_form` implementation returns every input's literal `el.value`, including password fields; the new `gnippets-signup-otp-disposable` scenario explicitly fills a random password and then requires `verify_form`. Consequently, that password is included in the cloud run updates sent over the bridge and persisted remotely even though the later CI artifact sanitizer removes it. Redact sensitive form field values—or all `verify_form` result values—in strict mode before publishing the update.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":204}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Increase the timeout for serial cloud-smoke runs**\\n\\nWhen the newly exposed `cloud-smoke` pack is dispatched with the supported concurrency value `1`, its configured execution budgets total about 83 minutes before browser provisioning, `npm ci`, tests, artifact handling, and cleanup: Wikipedia and NYTimes each have preload and main-run waits, Forms adds preload, main-run, and scheduled-job waits, and the remaining two scenarios add their own waits. The workflow's 90-minute job timeout can therefore terminate a valid serial run before `ci/run.mjs` writes the suite report or finishes cleanup. Fresh evidence beyond the earlier dedicated-workflow finding is that this commit adds `cloud-smoke` to this separate manual workflow while it retains the shorter timeout; raise this workflow's timeout or disallow serial execution for this pack.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\".github/workflows/cloud-e2e.yml\",\"side\":\"RIGHT\",\"line\":12}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `44161f0027`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Match scheduled-job URLs that include query parameters**\\n\\n`waitForScheduledJobs` requests `/scheduled-jobs?job_id=task_1`, so this `endsWith('/scheduled-jobs')` check never matches. The mock then falls through to `JSON.parse(options.body)` for a GET request whose body is undefined, causing `npm run test:ci` to fail before the smoke suite can run; match the URL pathname or the route prefix including its query string.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"ci/test.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Preserve non-secret strings in strict structured results**\\n\\nWhen `strictSecretMode` is enabled for any structured cloud run whose schema contains legitimate text, this replaces every string in `cloudResult` with the same placeholder before `pushUpdate` assigns it to `run.result`. The run can therefore report `completed` while API consumers receive corrupted headlines, URLs, filenames, and other non-secret output; retain the validated result for the public response and sanitize only secret-bearing trace or persistence data.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `29d09b892d`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact strict-mode text updates before persistence**\\n\\nFresh evidence beyond the prior `done_json` comment is that strict sanitization is applied only to selected tool updates: ordinary `text` and `text_delta` updates fall through `cloudSafeUpdateData` unchanged, while consecutive deltas return before this call entirely. When a streaming provider emits prose alongside a tool call, a password or OTP repeated in that prose remains in `run.updates` and is persisted/published even though the corresponding `done_json` call and result are redacted; redact or suppress textual updates for strict-secret runs as well.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Raise the timeout above the serial smoke budget**\\n\\nEven after the earlier timeout finding prompted an increase to 120 minutes, the `smoke` job still runs `cloud-smoke` serially: the five scenarios can occupy about 83 minutes across their preload, main-run, scheduled-job, and two-minute wait buffers, and `waitForBrowser` permits another 50 minutes across five sessions. Thus slow-but-bounded execution can exceed the job limit before accounting for installation, tests, artifact writing, and cleanup, causing GitHub Actions to terminate the process before the report and cleanup complete; increase the timeout further or parallelize the pack.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\".github/workflows/webbrain-cloud-smoke.yml\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `70ad5d8e3a`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in d27ee256.\\n\\nStrict mode redacted a list of known-risky tools and let everything else through, which was the wrong shape — the same OTP comes back out of `get_accessibility_tree`/`read_page` too, not just prose. It now denies by default: `text`/`text_delta` content is replaced, `error`/`run_status` drop their `message` (which carries the model's final response), non-`done_json`/`verify_form` tool results reduce to `success` + HTTP status, and tool args to the scalar keys grading reads. The consecutive-delta branch you flagged now routes through `cloudSafeUpdateData` instead of appending raw content onto the stored row.\\n\\n`clarify` is the one deliberate carve-out — a caller has to read the question to answer it — and that is commented in the source.\\n\\nCovered by a new fixture in `ci/cloud-capture.test.mjs` that publishes an OTP through page reads, streamed and final prose, a script argument, and the structured result, then asserts it appears in neither the snapshot nor the persisted rows. It fails against the pre-fix code.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in d27ee256.\\n\\nYour arithmetic matches mine — I get ~133 min for the pack serially (5 × 10 min `waitForBrowser` = 50, plus preload/run/scheduled budgets and the 2-minute buffers), against a 120-minute job.\\n\\nRaised to 150, and `.github/workflows/cloud-e2e.yml` to 330 since manual dispatch can pick `--pack all --concurrency 1` (~305 min). Rather than another literal that drifts, `ci/test.mjs` now derives the bound from the catalog and asserts each workflow covers the widest pack it can run, so adding a scenario fails the test instead of quietly shrinking the margin.\\n\\nAlso fixed the harm behind the finding: a killed job skips every `finally`, so `ci/run.mjs` now tracks in-flight browser sessions and Gnippets fixtures and releases them on SIGINT/SIGTERM/SIGHUP. Separately, `waitForRunWithClarifications` was restarting the full timeout after every answered clarification (five questions on a 10-minute scenario licensed 72 minutes) — it uses one shared deadline now, which also tightens the worst case above.\",\"path\":\".github/workflows/webbrain-cloud-smoke.yml\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Validate every advertised JSON Schema combinator**\\n\\nWhen a cloud caller supplies an `output_schema` using `const`, `anyOf`, `oneOf`, `allOf`, or `$ref`, this change classifies it as JSON Schema, but `validateCloudOutput` never evaluates those keywords. For example, `7` against `{anyOf:[{type:'string'},{type:'boolean'}]}` returns `ok: true`, so `done_json` can mark the run completed and publish a result that violates the caller's contract; either implement these keywords or reject them as unsupported.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/cloud-output.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve nullable semantics for optional shorthand fields**\\n\\nWhen an optional shorthand property is explicitly `null`, such as `{nickname: 'string?'}`, `validateCloudOutput` accepts it, but this converter strips `?` and advertises only `{type:'string'}`. `validateToolArguments` consequently rejects the `done_json` call before runtime validation, even though the output is valid under the supplied shorthand schema; include `null` in the generated type or stop treating `null` as valid for optional shorthand fields.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/tools.js\",\"side\":\"RIGHT\",\"line\":1342}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `d27ee256e0`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in 6cb5c65a — and you are right that this one was a regression I introduced, not a pre-existing gap. Before the change an unrecognized combinator fell through to the shorthand branch and got rejected (for the wrong reason, but rejected); after it, `{anyOf:[{type:\\\"string\\\"},{type:\\\"boolean\\\"}]}` classified as JSON Schema and validated `7` clean.\\n\\nImplemented rather than rejected, since callers legitimately use these: `const`, `anyOf`, `oneOf` (exactly-one), and `allOf` are evaluated via a nested `validateCloudOutput` call so a branch check does not pollute the caller's error list. `$ref` is reported as unsupported instead — resolving it properly needs a `$defs` resolver, and failing closed with a clear message beats silently publishing an unvalidated result.\\n\\n`validateValue` in `tool-arguments.js` is permissive on these keywords, which is the right split: it fails open on what it does not understand, and `validateCloudOutput` enforces the contract. So no false rejection at the argument gate.\\n\\nTen combinator cases added to `test/run.js`, run against both trees; they fail on d27ee256.\",\"path\":\"src/chrome/src/agent/cloud-output.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in 6cb5c65a, taking your first option — the generated type now includes `null`.\\n\\nWidening the advertised type is the safer of the two: `validateCloudOutput` has accepted an explicit null for optional shorthand all along, so tightening it instead would change behavior for existing callers. `nickname: \\\"string?\\\"` now advertises `{\\\"type\\\":[\\\"string\\\",\\\"null\\\"]}` and `tags: \\\"string[]?\\\"` becomes `{\\\"type\\\":[\\\"array\\\",\\\"null\\\"],\\\"items\\\":{\\\"type\\\":\\\"string\\\"}}`. A field declared `any` already permitted null and is left alone.\\n\\nThis is the same advertised-stricter-than-enforced asymmetry as the free-form-object bug, just pointing the other way, so the new test asserts the two validators agree rather than checking either in isolation. It also pins that widening does not slacken the declared type: `nickname: 42` is still rejected.\",\"path\":\"src/chrome/src/agent/tools.js\",\"side\":\"RIGHT\",\"line\":1342}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `6cb5c65a73`\\n \\n\\n

ℹ️ About Codex in GitHub

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in b338fd0a, and I changed approach rather than adding another carve-out.\\n\\nYou are right that the prompt is not a redaction boundary. But enumerating update types is what produced this finding and the two before it — each round redacted the types someone had thought of, and `clarify` was simply the last one left. So strict runs now redact by *value*: whatever the run types into a page, plus any value sitting under a key the scrubber already treats as sensitive, is remembered and struck from the text of every later update. Clarifications, warnings, captcha diagnostics, and anything added to this file later are covered without being named. The literals live in a map outside the run object so they cannot reach session storage, and are dropped when the run ends.\\n\\nThe clarification stays answerable, which was your constraint: `clarifyId`, `options`, and the question survive, with the secret replaced by `[redacted strict value]`. The CI driver regex-matches that question and still does.\\n\\nOne limit is now explicit in the source instead of undiscovered: a secret the model only ever *reads* out of an ordinary field — an OTP in the body text of an inbox message, not under a key named `otp` — never reaches this code in a recognizable form, so a clarification quoting it still rests on the prompt boundary alone. Closing that means either blanking clarification text, which makes a strict run unanswerable, or guessing at entropy in prose. I took the documented limit over either.\\n\\nVerified by emitting all fifteen update types with an embedded secret and asserting it appears in neither the snapshot nor the persisted rows.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in b338fd0a. This one was mine and it was avoidable — I fixed deep equality in `validateCloudOutput` and left `validateToolArguments` on `Object.is`, after twice writing that the two validators have to agree on any schema they both see.\\n\\nBoth now import one exported `jsonDeepEqual`. And rather than fix the next instance when it is reported, the test is now a sweep: fourteen schema/result pairs covering enum (scalar, object, array), const, nullable optionals, free-form objects, shorthand, and closed schemas, asserting the gate and the cloud validator return the same verdict for each, in both trees. `const` stays unenforced at the gate deliberately — failing open there and enforcing in the cloud validator is the split I described earlier for the combinators.\",\"path\":\"src/chrome/src/agent/tools.js\",\"side\":\"RIGHT\",\"line\":1386}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in b338fd0a. Setup now ends where it actually ends: a `reachedRunStart` flag is set once `startRun` returns a run id, and the catch only assigns `setupError` before that point.\\n\\nWith `setupError` unset, `inferStuckAt` reads the run instead of short-circuiting, so a timeout returns `execution` (or `planning`/`navigation`, depending on what the updates show), a trace-export failure after a completed run falls through to `verification`, and provisioning failures still report `setup`. The error artifact is written either way, so nothing is lost from the report. Three cases added to `ci/test.mjs`.\",\"path\":\"ci/run.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact terminal output for unstructured strict runs**\\n\\nWhen `strictSecretMode` is enabled without an `output_schema`, this conditional takes the raw-content branch, and the same content is subsequently assigned to `run.result`. Unlike the previously fixed update rows, these run-level `content` and `result` fields are returned over the bridge and persisted, so a final response that repeats a password, token, or OTP still escapes strict mode; apply strict redaction to terminal fields regardless of whether the run is structured.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact numeric secrets in structured payloads**\\n\\nThis strict-mode redactor replaces only string leaves, so a model that serializes a six-digit OTP as a number—such as `verification_code: 123456`—publishes it unchanged in the `done_json` call/result update. This also occurs on an invalid `done_json` attempt because `tool_call` is emitted before the argument-rejection result, and neither the later known-string replacement nor key scrubber recognizes a generic `verification_code` numeric value; redact numeric credential values as well or suppress the structured payload entirely.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `b338fd0a11`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in a1dfec9e.\\n\\nAll four terminal fields — `content`, `result`, `finalUrl`, `error` — now go through the run's value redaction, structured or not, rather than only the structured branch. `finalUrl` was worth including for the same reason: a confirmation URL can carry a token in a query parameter.\\n\\nI chose value redaction over blanking. With no output schema that final text *is* the result, so blanking would leave the run with nothing; instead the answer comes back readable with the literal struck (`\\\"Signup finished. The code was [redacted strict value].\\\"`). That option only became available once b338fd0a added value-based redaction — blanking really was the only alternative before it.\\n\\nSame documented limit applies as for clarifications: a secret the model reads out of ordinary prose and never types is not registered, so it still rests on the strict prompt. Everything typed, or surfaced under a key the scrubber knows, is struck.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in a1dfec9e. Numbers are redacted alongside strings now.\\n\\nThis one my own review walked past, and worse: when I routed `run.result` through this redactor earlier in the branch I described preserving numbers as a *feature*, because scenario grading reads outcome flags. It is both — and I only checked the half that helped me.\\n\\nBooleans and null still survive, since neither can encode a credential and a `true` outcome flag is what grading asserts on. The consequence is that a strict run's structured output is assertable on booleans only, which is now stated in the source; the signup scenario's five checks are all booleans, and it still grades 100.\\n\\nYour secondary point is the sharper one and is covered: the `done_json` `tool_call` is published before argument validation can reject it, so the args are a publication path in their own right. The new fixture asserts through the call args, the result, and `run.result`, over every JSON leaf type — number, string, nested array of numbers, boolean, false, null — in both the snapshot and the persisted rows.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls check\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `a1dfec9ea6`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Preserve schema-valid values in strict run results**\\n\\nFor any strict cloud run whose `output_schema` contains legitimate string or numeric fields, this assigns the redacted `cloudResult` to the public `run.result`, so a successfully validated value such as `{name:\\\"item\\\", count:3}` is returned as placeholders while the run still reports `completed`. Fresh evidence beyond the earlier string-result finding is that the new leaf redactor now replaces both strings and numbers before this assignment; keep the schema-valid public result intact while sanitizing only persistence/trace data, or make strict output contracts explicitly reject those types.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Remember credentials embedded in strict fetch bodies**\\n\\nWhen a strict run generates a credential only inside a mutating `fetch_url` body, this collector never records it because tool calls are inspected only for text-entry tools. In the new Mail.tm scenario, the disposable-account password is created in the JSON body of `POST /accounts`; although that body update is hidden, a later `clarify` payload quoting the password is retained and published because value redaction does not know it. Fresh evidence beyond the earlier clarification finding is this untracked API-body credential path; parse or otherwise register sensitive fetch-body values before discarding the arguments.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in eb3ed027. The collector only looked at text-entry arguments, so a credential that is minted but never typed was invisible to it — and that is precisely the Mail.tm flow, where the account password is created inside the `POST /accounts` body and never touches a form field.\\n\\nSensitive-keyed values in any tool call's arguments are registered now, and the request body is parsed as JSON or form encoding to reach the ones nested inside it. Verified end to end on that flow: the password is struck from the later clarification, from the done_json summary, and from the persisted rows, without ever having been typed.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Fixed in eb3ed027, and you are right that this was an over-correction on my side one commit earlier. Redacting the public result by leaf type satisfied strict mode by making the run useless: `completed`, with every string and number replaced by a placeholder.\\n\\nTook your first option. The two consumers want different things, so they now get different redactors. The update row is trace and persistence with no contract to honour and keeps the blunt leaf-type redaction. `run.result` and `run.summary` are the caller's answer, so they take value redaction — registered credentials struck, everything the schema declared left intact. `{name: \\\"item\\\", count: 3}` comes back as itself.\\n\\nThe case behind the previous finding stays closed because the value redactor now also matches a number against a registered secret's string form: an OTP typed as text and returned as `verification_code: 481920` is struck, while `count: 3` is not. That does mean the public result depends on registration rather than on type — a credential the model invents in the result and never types or exposes under a sensitive key would survive there, though it is still blanked in the trace row. That is the trade I took over returning placeholders; the alternative you offered — rejecting string and numeric fields in strict output contracts outright — is a bigger product decision and I have flagged it to the repo owner rather than making it unilaterally.\\n\\n`run.summary` moved to value redaction too, so it stops being the one terminal field playing by different rules.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls check\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact secrets first observed in page text**\\n\\nWhen an OTP or token first appears only in ordinary inbox/page text and the model repeats it in a later clarification, `collectSensitiveStrings` records nothing because it only recognizes values beneath sensitive-looking keys. The `clarify` update and `pendingInput` can therefore publish the literal secret despite strict mode. Fresh evidence beyond the earlier clarification finding is the newly committed known-limit path immediately above this call, which explicitly leaves page-body OTPs dependent on the prompt; strict-secret enforcement should not rely on model compliance.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":860}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Accept const values that resemble shorthand tokens**\\n\\nWhen a caller supplies the valid JSON Schema `{ \\\"const\\\": \\\"string\\\" }`, this predicate treats `\\\"string\\\"` as a shorthand type token and therefore classifies the whole schema as shorthand. `done_json` then advertises an object with a required `const` string field, while runtime validation rejects the intended literal string result. Fresh evidence beyond the earlier schema-disambiguation finding is this collision between a valid `const` value and the shorthand token vocabulary; preserve explicit JSON Schema semantics for such values or provide an unambiguous schema discriminator.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/cloud-output.js\",\"side\":\"RIGHT\",\"line\":52}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `eb3ed02738`\\n \\n\\n

ℹ️ About Codex in GitHub

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `28324ec5ef`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Register values from credential-labeled form fields**\\n\\nWhen a strict run calls top-frame `verify_form` on a prefilled credential, the result represents it as sibling fields such as `{name: \\\"password\\\", value: \\\"secret\\\"}`; this recursion only treats descendants of a sensitive *key* as sensitive, so the `value` is never registered. Although the immediate `verify_form` update is masked, the model received the raw value and can repeat it in a later clarification or terminal result, which is then published unchanged. Fresh evidence beyond the earlier `verify_form` result finding is this sibling-label path through the new value registry; correlate `name`/`type`/`label` with the field's value when collecting secrets.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":290}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Fail closed for oversized credential request bodies**\\n\\nWhen a strict `fetch_url` call has a request body over 10,000 characters, this early return skips credential collection entirely. The tool-call body itself is masked, but the model still saw its password/token fields and can quote one later in a clarification or public terminal result; because the value registry never learned it, that later publication is not redacted. Fresh evidence beyond the earlier fetch-body finding is this hard size cutoff; oversized bodies should trigger fail-closed scalar redaction or bounded credential extraction rather than silently disabling protection.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Reject unsupported JSON Schema constraints**\\n\\nWhen an `output_schema` combines a recognized `type` with constraints such as `minItems`, `maxItems`, `pattern`, `minimum`, or `maximum`, this classifies and advertises the whole object as JSON Schema, but `validateCloudOutput` never evaluates those keywords. For example, `[]` passes `{type:\\\"array\\\",minItems:3}` and `10` passes `{type:\\\"number\\\",maximum:5}`, so `done_json` can complete a cloud run with a result that violates the caller's contract whenever the provider does not enforce the tool schema itself; implement these constraints or reject schemas containing unsupported keywords.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/cloud-output.js\",\"side\":\"RIGHT\",\"line\":88}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `0f7af02940`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the caller's additionalProperties default**\\n\\nWhen a JSON Schema object declares `properties` but omits `additionalProperties`, JSON Schema permits extra keys by default; however, passing the generated `done_json` tool through `closeToolDefinitions` recursively adds `additionalProperties: false` to the caller's result schema. A result such as `{name: \\\"x\\\", extra: 1}` therefore passes `validateCloudOutput` against `{type: \\\"object\\\", properties: {name: {type: \\\"string\\\"}}}` but is rejected by `validateToolArguments` before runtime validation, so preserve explicit caller semantics rather than closing these embedded output-schema nodes.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/tools.js\",\"side\":\"RIGHT\",\"line\":1503}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Count Unicode characters consistently in done_json**\\n\\nWhen the forwarded output schema uses `minLength` or `maxLength` and a result contains an astral Unicode character, the two validators disagree: `validateCloudOutput` correctly counts code points with `[...item].length`, while `validateToolArguments` counts UTF-16 code units with `value.length`. For example, an emoji is valid under `{type: \\\"string\\\", maxLength: 1}` at runtime but the advertised `done_json` argument gate rejects it before dispatch; use the same JSON Schema length semantics in both validators.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/tools.js\",\"side\":\"RIGHT\",\"line\":1386}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `fb6ccb71b1`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Register navigation URLs before terminal redaction**\\n\\nWhen a strict run follows a credential-bearing capability URL through `navigate`, this collector registers URL components only for `fetch_url`. The generic strict-mode masking hides the `navigate` arguments, but `run.finalUrl` is later value-redacted without knowing that URL and `cloudSnapshot` publishes its full path and query. Unlike the previously addressed `fetch_url` path, the fresh evidence here is that navigation URLs never enter the secret registry; collect URL-bearing arguments from `navigate` and equivalent navigation tools as well.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Apply object keywords only to object instances**\\n\\nWhen a caller supplies a type-agnostic JSON Schema such as a `$schema`-marked `{properties: {...}}`, `{required: [...]}`, or `{additionalProperties: false}`, JSON Schema requires those keywords to be ignored for non-object instances. This branch instead rejects every scalar with `expected object with properties`; for example, the valid string result for `{$schema: \\\"…\\\", properties: {a: {type: \\\"string\\\"}}}` is rejected and can exhaust the run's single repair attempt. Evaluate these keywords only when `item` is an object and let an explicit `type: \\\"object\\\"` enforce objectness.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/cloud-output.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `0382cecaa0`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Recognize verification-code fields in strict request bodies**\\n\\nWhen a strict run sends an OTP through `fetch_url` as `{\\\"verification_code\\\":123456}` or `{\\\"code\\\":123456}`, this parsed-body walk passes it to `collectSensitiveStrings`, but `isSensitiveCloudKey` recognizes neither normalized key, so the literal never enters the run's secret registry. The immediate call is masked, but a later clarification, unstructured terminal response, or public `done_json` result can publish `123456` unchanged. Fresh evidence beyond the earlier numeric-secret finding is this common request-body label path; extend the credential-key detector or fail closed for unrecognized scalar body fields.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":470}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Recognize type-agnostic JSON Schema constraints**\\n\\nWhen a caller supplies a valid type-agnostic schema such as `{minLength: 3}` without the optional `$schema` or `type`, this detector returns false because the supported constraint keywords are absent from `JSON_SCHEMA_KEYWORD_SHAPES`. Validation then treats the document as shorthand and rejects even `\\\"abc\\\"` with `expected object`; boolean `items` and boolean combinator branches are misclassified similarly. Fresh evidence beyond the earlier constraint finding is that the implemented constraints are reachable only after this incomplete classification, so recognize their schema-shaped values here.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/agent/cloud-output.js\",\"side\":\"RIGHT\",\"line\":90}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `5a125a3941`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex pls review\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nhttps://github.com/esokullu/webbrain/blob/3c0b5b2e1db11711165761a6c4d61179a211a36a/src/chrome/src/cloud-runs.js#L939-L941\\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve a false root output schema**\\n\\nWhen a caller supplies the valid JSON Schema boolean `false`, this `||` chain converts it to `null`. The agent therefore receives no `done_json` tool, and the controller can report an ordinary prose completion instead of a structured run that necessarily fails validation. Use presence/nullish checks rather than truthiness so boolean root schemas retain their JSON Schema semantics.\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Avoid treating every URL segment as a secret**\\n\\nIn a strict structured run that visits an ordinary URL such as `https://example.com/profile`, this registers `profile` as a secret, so a valid public result like `{section: \\\"profile\\\"}` is changed to a redaction placeholder after schema validation. Query keys and benign values are registered just as broadly, corrupting legitimate caller-visible results whenever they repeat normal URL components. Fresh evidence beyond the earlier result-redaction finding is the later URL collector's unconditional registration of every path segment and query entry; restrict value redaction to credential-like URL components while continuing to suppress complete URLs from trace data.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"## CodeQL / Insecure randomness\\n\\nThis uses a cryptographically insecure random number generated at [Math.random()](1) in a security context.\\n\\n[Show more details](https://github.com/esokullu/webbrain/security/code-scanning/143)\",\"path\":\"src/chrome/src/cloud-runs.js\",\"side\":\"RIGHT\",\"line\":878}","text_elements",[],{"_604":2229,"_583":584,"_606":590},{"_607":2230,"_609":-5,"_42":-5,"_611":2231,"_613":-5,"_97":337,"_93":615},[2232],{"_616":590},{"_46":2225,"_93":639},{"_604":2234,"_583":584,"_606":590},{"_607":2235,"_609":-5,"_42":-5,"_611":2236,"_613":-5,"_97":337,"_93":615},[2237],{"_616":590},{"_46":2238,"_93":639},"\n /workspace/webbrain\n bash\n 2026-08-07\n Etc/UTC\n /workspace/webbrain\n",{"_604":2240,"_583":584,"_606":590},{"_607":2241,"_609":-5,"_42":-5,"_611":2242,"_613":-5,"_97":2243,"_93":615},[2244],{"_616":590},"developer",{"_46":2245,"_93":639},"Do not spawn sub-agents unless the user or applicable AGENTS.md/skill instructions explicitly ask for sub-agents, delegation, or parallel agent work.",{"_604":2247,"_583":584,"_606":590},{"_607":2248,"_609":-5,"_42":-5,"_611":2249,"_613":-5,"_97":2243,"_93":615},[2250],{"_616":590},{"_46":2251,"_93":639},"You are `/root`, the primary agent in a team of agents collaborating to fulfill the user's goals.\n\nAt the start of your turn, you are the active agent.\nYou can spawn sub-agents to handle subtasks, and those sub-agents can spawn their own sub-agents.\nAll agents in the team, including the agents that you can assign tasks to, are equally intelligent and capable, and have access to the same set of tools.\n\nYou can use `spawn_agent` to create a new agent, `followup_task` to give an existing agent a new task and trigger a turn, and `send_message` to pass a message to a running agent without triggering a turn.\nChild agents can also spawn their own sub-agents.\nYou can decide how much context you want to propagate to your sub-agents with the `fork_turns` parameter.\n\nYou will receive messages in the analysis channel in the form:\n```\nMessage Type: MESSAGE | FINAL_ANSWER\nTask name: \nSender: \nPayload:\n\n```\nThey may be addressed as to=/root\n\nNote that collaboration tools cannot be called from inside `functions.exec`. Call `spawn_agent`, `send_message`, `followup_task`, `wait_agent`, `interrupt_agent`, and `list_agents` only as direct tool calls using the recipient shown in their tool definitions, such as `to=functions.collaboration.spawn_agent`, since they are intentionally absent from the `functions.exec` `tools.*` namespace. Available tools in `functions.exec` are explicitly described with a `tools` namespace in the developer message.\n\nAll agents share the same directory. In detail:\n- All agents have access to the same container and filesystem as you.\n- All agents use the same current working directory.\n- As a result, edits made by one agent are immediately visible to all other agents.\n\nThere are 4 available concurrency slots, meaning that up to 4 agents can be active at once, including you.",{"_604":2253,"_583":584,"_606":590},{"_607":2254,"_609":-5,"_42":-5,"_611":2255,"_613":-5,"_97":2243,"_93":615},[2256,2257],{"_616":590},{"_46":2259,"_93":639},{"_46":2258,"_93":639},"\n## Skills\nA skill is a set of instructions provided through a `SKILL.md` source. Below is the list of skills that can be used. Each entry includes a name, description, and source locator. `file` locators are on the host filesystem, `environment resource` locators are owned by an execution environment, `orchestrator resource` locators are opaque non-filesystem resources, and `custom resource` locators use their provider's access mechanism.\n### Available skills\n- imagegen: Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG/vector/code-native assets, extending an established icon or logo system, or building the visual directly in HTML/CSS/canvas. (file: /opt/codex/skills/.system/imagegen/SKILL.md)\n- openai-docs: Use when the user asks how to build with OpenAI products or APIs, asks about Codex itself or choosing Codex surfaces, needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; use OpenAI docs MCP tools for non-Codex docs questions, use the Codex manual helper first for broad Codex self-knowledge, and restrict fallback browsing to official OpenAI domains. (file: /opt/codex/skills/.system/openai-docs/SKILL.md)\n- plugin-creator: Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, valid manifest defaults, and personal-marketplace entries by default. Use when Codex needs to create a new personal plugin, add optional plugin structure, generate or update marketplace entries for plugin ordering and availability metadata, or update an existing local plugin during development with the CLI-driven cachebuster and reinstall flow. (file: /opt/codex/skills/.system/plugin-creator/SKILL.md)\n- skill-creator: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations. (file: /opt/codex/skills/.system/skill-creator/SKILL.md)\n- skill-installer: Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos). (file: /opt/codex/skills/.system/skill-installer/SKILL.md)\n","\nFilesystem sandboxing defines which files can be read or written. `sandbox_mode` is `danger-full-access`: No filesystem sandboxing - all commands are permitted. Network access is enabled.\nApproval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.\n","turn/started",{"_583":584,"_88":2262},{"_104":-5,"_42":590,"_591":2263,"_593":594,"_595":596,"_597":2264},[],"inProgress",{"_597":2266,"_583":584},{"_2267":2268,"_93":2269},"activeFlags",[],"active","thread/started",{"_2272":2273},"thread",{"_2274":-5,"_2275":-5,"_2276":2277,"_2278":596,"_649":650,"_2279":15,"_2280":-5,"_2281":-5,"_2282":-5,"_2283":2284,"_42":584,"_2285":2286,"_195":-5,"_2287":-5,"_168":2288,"_2289":213,"_2290":596,"_2291":584,"_656":2292,"_597":2293,"_2294":-5,"_78":2295,"_2296":596},"agentNickname","agentRole","cliVersion","0.144.0-alpha.4","createdAt","ephemeral","extra","forkedFromId","gitInfo","historyMode","legacy","modelProvider","openai","parentThreadId","/opt/codex/sessions/2026/08/07/rollout-2026-08-07T16-01-20-019fdcf5-2158-7481-9f7b-b1ee91a38d29.jsonl","preview","recencyAt","sessionId","vscode",{"_93":601},"threadSource",[],"updatedAt",[],"messages",[2300],{"_42":2301,"_2302":2303,"_2304":2305,"_2306":2305,"_607":2307,"_597":2308,"_609":-5,"_2309":32,"_2310":2311,"_2312":2313,"_2314":-5},"a8427fad-ff89-4f5a-a102-bb064fbb0f23","author",{"_97":337,"_195":-5,"_2310":2323},"create_time",1786118479.213064,"update_time",{"_2319":46,"_2320":2321},"finished_successfully","weight","metadata",{"_2315":2316},"recipient","all","channel","l1239dk1",{"_2317":2318},"inline_comments",[],"content_type","parts",[2322],"@codex pls check\nAdd WebBrain Cloud CI integration\n\n\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Reject failed tool requests as evidence**\n\nThe request rubric considers only `tool_call` updates, so a rejected or failed request is graded as successfully exercised without checking its corresponding `tool_result`. In the new signup smoke test this is especially problematic because the Mail.tm `POST` is blocked unless API mutations are enabled: the blocked call can still satisfy “Created a disposable Mail.tm account,” and the scenario may subsequently complete through the UI, producing a false pass. Correlate calls with successful results and, for HTTP evidence, verify the returned success/status.\n\nUseful? React with 👍 / 👎.\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Make the required Mail.tm POST executable**\n\nFor `gnippets-signup-otp-disposable`, the rubric requires `POST https://api.mail.tm/accounts`, but this run request never supplies `api_mutations_allowed`. The agent's mutating-`fetch_url` guard therefore rejects that POST unless `/allow-api` was enabled, while the automated clarification only authorizes disposable-email use and cannot issue that slash command; moreover, the loaded Mail.tm skill directs the normal path through the UI. As configured, a policy-compliant run cannot genuinely exercise the API operation the smoke test claims to require, so explicitly authorize and request the isolated API path or remove the API-specific check.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `66cfb5347e`\n \n\n

ℹ️ About Codex in GitHub

\n
\n\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\n- Open a pull request for review\n- Mark a draft as ready\n- Comment \"@codex review\".\n\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\n\n\n\n\nCodex can also answer questions or update the PR. Try commenting \"@codex address that feedback\".\n \n

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Require successful results for skill and tool checks**\n\nWhen `load_skill` or another required tool is rejected or fails, these checks still pass solely because a matching `tool_call` exists. Although the updated `toolRequests` path now correlates calls with successful results, this fresh evidence shows the `skills` and `tools` loops still do not, so the signup smoke test can report that both skills were loaded and required instrumentation was exercised even when their results have `success: false`; correlate these checks with their `tool_result` records as well.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Remove capability URLs from sensitive artifacts**\n\nFor the sensitive Gnippets scenario, `final_url` is the high-entropy fixture capability URL derived from `setup.app_url`, but both this sanitizer and `sanitizeRun` retain it verbatim. If fixture deletion fails, the workflow still uploads artifacts via its `if: always()` step, exposing a live bearer-style URL until expiration despite the sensitive-artifact policy; omit the URL or retain only non-capability origin information.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `cd80970f2b`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Allow the serial smoke pack to reach its configured timeouts**\n\nWith the workflow running `cloud-smoke` at concurrency 1, the four scenarios allow 50 minutes of agent execution alone, because the Wikipedia and NYTimes scenarios each perform a preload run with the same timeout before their main run; `waitForRun` also adds two-minute buffers and browser provisioning and tests consume additional time. When multiple external sites are slow but still within their scenario budgets, this 45-minute job limit terminates Node before it can write the suite report or execute the browser/fixture cleanup in `finally`, so increase the job timeout or run scenarios concurrently.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Trigger the smoke workflow for cloud bridge changes**\n\nThe changed `src/chrome/src/offscreen/cloud-bridge.js` controls the cloud handshake and now advertises `run_modes_v1`, but none of these push-path entries covers that file. A future bridge-only change can therefore land on `main` without immediately running the cloud smoke pack that depends on the bridge, leaving failures undiscovered until the next scheduled run; include the offscreen bridge path in this filter.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `7885329a55`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Validate scheduled job targets and prompts**\n\nFor the Google Forms smoke scenario, these checks accept any two `schedule_task` calls whose jobs later report `completed`/`success`; they never verify the requested Forms URL, the 0/60-second schedules, the distinct A/B prompts, or that the returned IDs match the result fields. A run can therefore pass after scheduling two unrelated successful jobs without exercising either form submission, so retain and grade the scheduled job definitions or the corresponding call arguments.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the scheduled-wait failure stage**\n\nWhen the main Google Forms run succeeds but either scheduled job remains nonterminal past `scheduled_timeout_ms`, this rethrow reaches the outer catch and is assigned to `setupError`; `inferStuckAt` then unconditionally reports `setup`. The smoke summary consequently attributes a post-run scheduled-execution timeout to fixture setup, obscuring the actual failure stage; track this error separately as scheduled execution or verification.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `c53cb8c5cd`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `56e9b3e21b`\n \n\n

ℹ️ About Codex in GitHub

\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact verify_form results in strict cloud runs**\n\nWhen a strict-secret cloud run calls `verify_form`, only `fetch_url` results are sanitized here, so the result falls through unchanged. The top-frame `verify_form` implementation returns every input's literal `el.value`, including password fields; the new `gnippets-signup-otp-disposable` scenario explicitly fills a random password and then requires `verify_form`. Consequently, that password is included in the cloud run updates sent over the bridge and persisted remotely even though the later CI artifact sanitizer removes it. Redact sensitive form field values—or all `verify_form` result values—in strict mode before publishing the update.\n\nUseful? React with 👍 / 👎.\n@codex pls review\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Increase the timeout for serial cloud-smoke runs**\n\nWhen the newly exposed `cloud-smoke` pack is dispatched with the supported concurrency value `1`, its configured execution budgets total about 83 minutes before browser provisioning, `npm ci`, tests, artifact handling, and cleanup: Wikipedia and NYTimes each have preload and main-run waits, Forms adds preload, main-run, and scheduled-job waits, and the remaining two scenarios add their own waits. The workflow's 90-minute job timeout can therefore terminate a valid serial run before `ci/run.mjs` writes the suite report or finishes cleanup. Fresh evidence beyond the earlier dedicated-workflow finding is that this commit adds `cloud-smoke` to this separate manual workflow while it retains the shorter timeout; raise this workflow's timeout or disallow serial execution for this pack.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `44161f0027`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Enforce strict-secret handling in done_json**\n\nWhen `strictSecretMode` is enabled for the new disposable-email/OTP scenario, this structured-output branch bypasses the strict `done` variants below and builds `done_json` without passing the strict flag. Its required `summary` remains an unrestricted string, and both the `done_json` call arguments and terminal summary are published by `cloud-runs.js`; the generic scrubber cannot recognize a password, token, or OTP embedded in prose. Consequently, if the model includes one of the generated credentials in its summary, the value is sent to and persisted by WebBrain Cloud despite strict mode, so use a strict `done_json` definition and/or redact its summary before publishing.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `38d906722a`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Scope scheduled-job reads to managed runs**\n\nWhen the cloud bridge is enabled, the newly allowlisted `cloud_scheduled_jobs` action returns `scheduler.listJobs({ tabId: null })`, which includes every locally stored scheduled job rather than only the job IDs created by the requesting cloud run. These summaries contain target URLs, prompts/results, and clarification state, so a managed sidecar polling two CI jobs can also receive unrelated user task history; require the caller's expected IDs and filter the response to those managed jobs.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0cc5619ca9`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Match scheduled-job URLs that include query parameters**\n\n`waitForScheduledJobs` requests `/scheduled-jobs?job_id=task_1`, so this `endsWith('/scheduled-jobs')` check never matches. The mock then falls through to `JSON.parse(options.body)` for a GET request whose body is undefined, causing `npm run test:ci` to fail before the smoke suite can run; match the URL pathname or the route prefix including its query string.\n\nUseful? React with 👍 / 👎.\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Preserve non-secret strings in strict structured results**\n\nWhen `strictSecretMode` is enabled for any structured cloud run whose schema contains legitimate text, this replaces every string in `cloudResult` with the same placeholder before `pushUpdate` assigns it to `run.result`. The run can therefore report `completed` while API consumers receive corrupted headlines, URLs, filenames, and other non-secret output; retain the validated result for the public response and sanitize only secret-bearing trace or persistence data.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `29d09b892d`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Trigger smoke tests for background bridge changes**\n\nWhen a push changes only `src/chrome/src/background.js`, this path filter skips the workflow even though the new `cloud_scheduled_jobs` bridge handler is implemented there and is required by the Google Forms smoke scenario. Include `src/chrome/src/background.js` so regressions in that handler are exercised on `main`.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `16d19db85b`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact strict-mode text updates before persistence**\n\nFresh evidence beyond the prior `done_json` comment is that strict sanitization is applied only to selected tool updates: ordinary `text` and `text_delta` updates fall through `cloudSafeUpdateData` unchanged, while consecutive deltas return before this call entirely. When a streaming provider emits prose alongside a tool call, a password or OTP repeated in that prose remains in `run.updates` and is persisted/published even though the corresponding `done_json` call and result are redacted; redact or suppress textual updates for strict-secret runs as well.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Raise the timeout above the serial smoke budget**\n\nEven after the earlier timeout finding prompted an increase to 120 minutes, the `smoke` job still runs `cloud-smoke` serially: the five scenarios can occupy about 83 minutes across their preload, main-run, scheduled-job, and two-minute wait buffers, and `waitForBrowser` permits another 50 minutes across five sessions. Thus slow-but-bounded execution can exceed the job limit before accounting for installation, tests, artifact writing, and cleanup, causing GitHub Actions to terminate the process before the report and cleanup complete; increase the timeout further or parallelize the pack.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `70ad5d8e3a`\n \n\n

ℹ️ About Codex in GitHub

\nFixed in d27ee256.\n\nStrict mode redacted a list of known-risky tools and let everything else through, which was the wrong shape — the same OTP comes back out of `get_accessibility_tree`/`read_page` too, not just prose. It now denies by default: `text`/`text_delta` content is replaced, `error`/`run_status` drop their `message` (which carries the model's final response), non-`done_json`/`verify_form` tool results reduce to `success` + HTTP status, and tool args to the scalar keys grading reads. The consecutive-delta branch you flagged now routes through `cloudSafeUpdateData` instead of appending raw content onto the stored row.\n\n`clarify` is the one deliberate carve-out — a caller has to read the question to answer it — and that is commented in the source.\n\nCovered by a new fixture in `ci/cloud-capture.test.mjs` that publishes an OTP through page reads, streamed and final prose, a script argument, and the structured result, then asserts it appears in neither the snapshot nor the persisted rows. It fails against the pre-fix code.\nFixed in d27ee256.\n\nYour arithmetic matches mine — I get ~133 min for the pack serially (5 × 10 min `waitForBrowser` = 50, plus preload/run/scheduled budgets and the 2-minute buffers), against a 120-minute job.\n\nRaised to 150, and `.github/workflows/cloud-e2e.yml` to 330 since manual dispatch can pick `--pack all --concurrency 1` (~305 min). Rather than another literal that drifts, `ci/test.mjs` now derives the bound from the catalog and asserts each workflow covers the widest pack it can run, so adding a scenario fails the test instead of quietly shrinking the margin.\n\nAlso fixed the harm behind the finding: a killed job skips every `finally`, so `ci/run.mjs` now tracks in-flight browser sessions and Gnippets fixtures and releases them on SIGINT/SIGTERM/SIGHUP. Separately, `waitForRunWithClarifications` was restarting the full timeout after every answered clarification (five questions on a 10-minute scenario licensed 72 minutes) — it uses one shared deadline now, which also tightens the worst case above.\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Validate every advertised JSON Schema combinator**\n\nWhen a cloud caller supplies an `output_schema` using `const`, `anyOf`, `oneOf`, `allOf`, or `$ref`, this change classifies it as JSON Schema, but `validateCloudOutput` never evaluates those keywords. For example, `7` against `{anyOf:[{type:'string'},{type:'boolean'}]}` returns `ok: true`, so `done_json` can mark the run completed and publish a result that violates the caller's contract; either implement these keywords or reject them as unsupported.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve nullable semantics for optional shorthand fields**\n\nWhen an optional shorthand property is explicitly `null`, such as `{nickname: 'string?'}`, `validateCloudOutput` accepts it, but this converter strips `?` and advertises only `{type:'string'}`. `validateToolArguments` consequently rejects the `done_json` call before runtime validation, even though the output is valid under the supplied shorthand schema; include `null` in the generated type or stop treating `null` as valid for optional shorthand fields.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `d27ee256e0`\n \n\n

ℹ️ About Codex in GitHub

\nFixed in 6cb5c65a — and you are right that this one was a regression I introduced, not a pre-existing gap. Before the change an unrecognized combinator fell through to the shorthand branch and got rejected (for the wrong reason, but rejected); after it, `{anyOf:[{type:\"string\"},{type:\"boolean\"}]}` classified as JSON Schema and validated `7` clean.\n\nImplemented rather than rejected, since callers legitimately use these: `const`, `anyOf`, `oneOf` (exactly-one), and `allOf` are evaluated via a nested `validateCloudOutput` call so a branch check does not pollute the caller's error list. `$ref` is reported as unsupported instead — resolving it properly needs a `$defs` resolver, and failing closed with a clear message beats silently publishing an unvalidated result.\n\n`validateValue` in `tool-arguments.js` is permissive on these keywords, which is the right split: it fails open on what it does not understand, and `validateCloudOutput` enforces the contract. So no false rejection at the argument gate.\n\nTen combinator cases added to `test/run.js`, run against both trees; they fail on d27ee256.\nFixed in 6cb5c65a, taking your first option — the generated type now includes `null`.\n\nWidening the advertised type is the safer of the two: `validateCloudOutput` has accepted an explicit null for optional shorthand all along, so tightening it instead would change behavior for existing callers. `nickname: \"string?\"` now advertises `{\"type\":[\"string\",\"null\"]}` and `tags: \"string[]?\"` becomes `{\"type\":[\"array\",\"null\"],\"items\":{\"type\":\"string\"}}`. A field declared `any` already permitted null and is left alone.\n\nThis is the same advertised-stricter-than-enforced asymmetry as the free-form-object bug, just pointing the other way, so the new test asserts the two validators agree rather than checking either in isolation. It also pins that widening does not slacken the declared type: `nickname: 42` is still rejected.\n@codex pls review\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `6cb5c65a73`\n \n\n

ℹ️ About Codex in GitHub

\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Fail closed when sensitive session settings are rejected**\n\nWhen browser provisioning returns a failed or partial `webbrain_config_result`, this path ignores it and starts the scenario anyway. For `gnippets-signup-otp-disposable`, that can leave `strictSecretMode` at its default `false` while the run handles a password, mailbox token, and OTP, allowing raw updates to be published remotely; inspect the returned configuration result and abort before starting any sensitive run unless all required settings were applied.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Compare JSON Schema const values structurally**\n\nWhen a caller uses an object or array as a JSON Schema `const`, the model's `done_json` argument is a separately parsed value, so `Object.is` can never match it even when its JSON structure is identical. Such a valid result is rejected twice and the cloud run fails; apply JSON Schema deep-equality semantics rather than reference identity.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Disambiguate shorthand fields from schema keywords**\n\nWhen a shorthand output schema has an ordinary field named `const`, `anyOf`, `oneOf`, `allOf`, or `$ref` (for example `{const: 'string'}`), this detector now classifies the whole object as JSON Schema instead of the documented shorthand form. Validation then either rejects the intended object or silently skips its required field, and `doneJsonResultSchema` advertises the same incorrect contract; require schema-shaped keyword values or an explicit schema marker before changing interpretation.\n\nUseful? React with 👍 / 👎.\nFixed in 7cce77cc. Good catch — `createIncognitoBrowser` has been surfacing `webbrain_config_result` all along and nothing read it, which made the redaction work in the preceding commits conditional on a setting nobody verified.\n\nA scenario that declares `session_settings` now aborts before `startRun` unless provisioning confirms every one of them. I applied it to any scenario with declared settings rather than only sensitive ones: if `scheduledRequireConsequentialConfirmation` silently failed to apply, that scenario's result is not meaningful either.\n\nOne caveat worth stating plainly: the cloud's response schema for `webbrain_config_result` is not in this repo, so `unappliedSessionSettings` accepts the shapes it plausibly takes — an echoed `settings` object (preferred, since it confirms the value and not just the key), an `applied` list, or any of the usual `ignoredKeys`/`rejected`/`unsupported`/`failed` lists — and treats silence as failure. That is the fail-closed direction you asked for, but it does mean that if provisioning returns nothing today, the two scenarios with declared settings will fail rather than run unprotected. That seemed like the right way to be wrong. If the real response shape is known, narrowing this to it would be strictly better.\n\nThe abort happens inside the existing `try`, so the `finally` still destroys the session — no leak. Nine unit cases in `ci/test.mjs` pin each way provisioning can decline, plus silence.\nFixed in 7cce77cc — and you are right that this repeated the exact bug the change was meant to fix. I dropped `description`/`required`/`additionalProperties` as signals because they are ordinary field names, then added `const`/`anyOf`/`$ref` and friends by name alone, which are equally ordinary field names.\n\nA keyword now has to carry a schema-shaped value: `properties` a plain object, `items` an object or array, `enum` an array, and the composition keywords a non-empty array whose every element is an object. `const` and `$ref` take free values, so the tell there is that a shorthand type token (`string`, `string[]`, `number?`) is never what a caller means by `{const: \"ok\"}` or `{$ref: \"#/$defs/x\"}` — which resolves your `{const: \"string\"}` example while keeping `{const: \"ok\"}` and nested `{status: {const: \"ok\"}}` working.\n\nI kept `const` as a classifier rather than dropping it: a bare `{const: \"ok\"}` appears as a child of a `properties` map all the time, and classifying that as shorthand would break the common case to fix the rare one.\n\nTested both directions in `test/run.js` — eight shorthand shapes that must not classify, seven schema shapes that must, and an end-to-end check that `{const: \"string\"}` is validated and advertised as shorthand, required field and all.\nFixed in 7cce77cc. `const` uses structural equality now — key-order independent, recursive through objects and arrays.\n\n`enum` had the identical defect (`Array.prototype.includes` is SameValueZero, so an object member could never match either) and is fixed in the same change, since it would have been the next comment.\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact clarification payloads in strict mode**\n\nWhen a strict cloud run asks for clarification after reading or generating a credential, this carve-out publishes the raw `question`, `options`, and `reason` and stores the same payload in `pendingInput`. If the model repeats an OTP, token, or password in that clarification, the key-based scrubber will not recognize it and the secret is persisted remotely; prompt instructions are not a sufficient redaction boundary, so sanitize the payload while retaining a safe question for the caller.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve structural equality for object enum results**\n\nWhen an output schema contains an object- or array-valued `enum`, spreading it into the `done_json` argument schema sends the separately parsed model value through `validateToolArguments`, whose enum check uses `Object.is`. A structurally identical value therefore fails at the argument gate before `validateCloudOutput` can apply its new deep-equality logic, making such a valid cloud output impossible to submit; the argument validator must use the same structural comparison.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the main-run failure stage**\n\nWhen `waitForRunWithClarifications` times out, it supplies the latest active run through `error.latest`, but this catch still assigns the error to `setupError`; `inferStuckAt` then returns `setup` before inspecting that run's updates. Trace-export and Gnippets-verification failures are similarly mislabeled, so execution or verification failures in the smoke report appear as provisioning failures even though scheduled failures now retain their own stage.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `7cce77cccc`\n \n\n

ℹ️ About Codex in GitHub

\nFixed in b338fd0a, and I changed approach rather than adding another carve-out.\n\nYou are right that the prompt is not a redaction boundary. But enumerating update types is what produced this finding and the two before it — each round redacted the types someone had thought of, and `clarify` was simply the last one left. So strict runs now redact by *value*: whatever the run types into a page, plus any value sitting under a key the scrubber already treats as sensitive, is remembered and struck from the text of every later update. Clarifications, warnings, captcha diagnostics, and anything added to this file later are covered without being named. The literals live in a map outside the run object so they cannot reach session storage, and are dropped when the run ends.\n\nThe clarification stays answerable, which was your constraint: `clarifyId`, `options`, and the question survive, with the secret replaced by `[redacted strict value]`. The CI driver regex-matches that question and still does.\n\nOne limit is now explicit in the source instead of undiscovered: a secret the model only ever *reads* out of an ordinary field — an OTP in the body text of an inbox message, not under a key named `otp` — never reaches this code in a recognizable form, so a clarification quoting it still rests on the prompt boundary alone. Closing that means either blanking clarification text, which makes a strict run unanswerable, or guessing at entropy in prose. I took the documented limit over either.\n\nVerified by emitting all fifteen update types with an embedded secret and asserting it appears in neither the snapshot nor the persisted rows.\nFixed in b338fd0a. This one was mine and it was avoidable — I fixed deep equality in `validateCloudOutput` and left `validateToolArguments` on `Object.is`, after twice writing that the two validators have to agree on any schema they both see.\n\nBoth now import one exported `jsonDeepEqual`. And rather than fix the next instance when it is reported, the test is now a sweep: fourteen schema/result pairs covering enum (scalar, object, array), const, nullable optionals, free-form objects, shorthand, and closed schemas, asserting the gate and the cloud validator return the same verdict for each, in both trees. `const` stays unenforced at the gate deliberately — failing open there and enforcing in the cloud validator is the split I described earlier for the combinators.\nFixed in b338fd0a. Setup now ends where it actually ends: a `reachedRunStart` flag is set once `startRun` returns a run id, and the catch only assigns `setupError` before that point.\n\nWith `setupError` unset, `inferStuckAt` reads the run instead of short-circuiting, so a timeout returns `execution` (or `planning`/`navigation`, depending on what the updates show), a trace-export failure after a completed run falls through to `verification`, and provisioning failures still report `setup`. The error artifact is written either way, so nothing is lost from the report. Three cases added to `ci/test.mjs`.\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact terminal output for unstructured strict runs**\n\nWhen `strictSecretMode` is enabled without an `output_schema`, this conditional takes the raw-content branch, and the same content is subsequently assigned to `run.result`. Unlike the previously fixed update rows, these run-level `content` and `result` fields are returned over the bridge and persisted, so a final response that repeats a password, token, or OTP still escapes strict mode; apply strict redaction to terminal fields regardless of whether the run is structured.\n\nUseful? React with 👍 / 👎.\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact numeric secrets in structured payloads**\n\nThis strict-mode redactor replaces only string leaves, so a model that serializes a six-digit OTP as a number—such as `verification_code: 123456`—publishes it unchanged in the `done_json` call/result update. This also occurs on an invalid `done_json` attempt because `tool_call` is emitted before the argument-rejection result, and neither the later known-string replacement nor key scrubber recognizes a generic `verification_code` numeric value; redact numeric credential values as well or suppress the structured payload entirely.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `b338fd0a11`\n \n\n

ℹ️ About Codex in GitHub

\nFixed in a1dfec9e.\n\nAll four terminal fields — `content`, `result`, `finalUrl`, `error` — now go through the run's value redaction, structured or not, rather than only the structured branch. `finalUrl` was worth including for the same reason: a confirmation URL can carry a token in a query parameter.\n\nI chose value redaction over blanking. With no output schema that final text *is* the result, so blanking would leave the run with nothing; instead the answer comes back readable with the literal struck (`\"Signup finished. The code was [redacted strict value].\"`). That option only became available once b338fd0a added value-based redaction — blanking really was the only alternative before it.\n\nSame documented limit applies as for clarifications: a secret the model reads out of ordinary prose and never types is not registered, so it still rests on the strict prompt. Everything typed, or surfaced under a key the scrubber knows, is struck.\nFixed in a1dfec9e. Numbers are redacted alongside strings now.\n\nThis one my own review walked past, and worse: when I routed `run.result` through this redactor earlier in the branch I described preserving numbers as a *feature*, because scenario grading reads outcome flags. It is both — and I only checked the half that helped me.\n\nBooleans and null still survive, since neither can encode a credential and a `true` outcome flag is what grading asserts on. The consequence is that a strict run's structured output is assertable on booleans only, which is now stated in the source; the signup scenario's five checks are all booleans, and it still grades 100.\n\nYour secondary point is the sharper one and is covered: the `done_json` `tool_call` is published before argument validation can reject it, so the args are a publication path in their own right. The new fixture asserts through the call args, the result, and `run.result`, over every JSON leaf type — number, string, nested array of numbers, boolean, false, null — in both the snapshot and the persisted rows.\n@codex pls check\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `a1dfec9ea6`\n \n\n

ℹ️ About Codex in GitHub

\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Preserve schema-valid values in strict run results**\n\nFor any strict cloud run whose `output_schema` contains legitimate string or numeric fields, this assigns the redacted `cloudResult` to the public `run.result`, so a successfully validated value such as `{name:\"item\", count:3}` is returned as placeholders while the run still reports `completed`. Fresh evidence beyond the earlier string-result finding is that the new leaf redactor now replaces both strings and numbers before this assignment; keep the schema-valid public result intact while sanitizing only persistence/trace data, or make strict output contracts explicitly reject those types.\n\nUseful? React with 👍 / 👎.\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Remember credentials embedded in strict fetch bodies**\n\nWhen a strict run generates a credential only inside a mutating `fetch_url` body, this collector never records it because tool calls are inspected only for text-entry tools. In the new Mail.tm scenario, the disposable-account password is created in the JSON body of `POST /accounts`; although that body update is hidden, a later `clarify` payload quoting the password is retained and published because value redaction does not know it. Fresh evidence beyond the earlier clarification finding is this untracked API-body credential path; parse or otherwise register sensitive fetch-body values before discarding the arguments.\n\nUseful? React with 👍 / 👎.\nFixed in eb3ed027. The collector only looked at text-entry arguments, so a credential that is minted but never typed was invisible to it — and that is precisely the Mail.tm flow, where the account password is created inside the `POST /accounts` body and never touches a form field.\n\nSensitive-keyed values in any tool call's arguments are registered now, and the request body is parsed as JSON or form encoding to reach the ones nested inside it. Verified end to end on that flow: the password is struck from the later clarification, from the done_json summary, and from the persisted rows, without ever having been typed.\nFixed in eb3ed027, and you are right that this was an over-correction on my side one commit earlier. Redacting the public result by leaf type satisfied strict mode by making the run useless: `completed`, with every string and number replaced by a placeholder.\n\nTook your first option. The two consumers want different things, so they now get different redactors. The update row is trace and persistence with no contract to honour and keeps the blunt leaf-type redaction. `run.result` and `run.summary` are the caller's answer, so they take value redaction — registered credentials struck, everything the schema declared left intact. `{name: \"item\", count: 3}` comes back as itself.\n\nThe case behind the previous finding stays closed because the value redactor now also matches a number against a registered secret's string form: an OTP typed as text and returned as `verification_code: 481920` is struck, while `count: 3` is not. That does mean the public result depends on registration rather than on type — a credential the model invents in the result and never types or exposes under a sensitive key would survive there, though it is still blanked in the trace row. That is the trade I took over returning placeholders; the alternative you offered — rejecting string and numeric fields in strict output contracts outright — is a bigger product decision and I have flagged it to the repo owner rather than making it unilaterally.\n\n`run.summary` moved to value redaction too, so it stops being the one terminal field playing by different rules.\n@codex pls check\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact secrets first observed in page text**\n\nWhen an OTP or token first appears only in ordinary inbox/page text and the model repeats it in a later clarification, `collectSensitiveStrings` records nothing because it only recognizes values beneath sensitive-looking keys. The `clarify` update and `pendingInput` can therefore publish the literal secret despite strict mode. Fresh evidence beyond the earlier clarification finding is the newly committed known-limit path immediately above this call, which explicitly leaves page-body OTPs dependent on the prompt; strict-secret enforcement should not rely on model compliance.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Accept const values that resemble shorthand tokens**\n\nWhen a caller supplies the valid JSON Schema `{ \"const\": \"string\" }`, this predicate treats `\"string\"` as a shorthand type token and therefore classifies the whole schema as shorthand. `done_json` then advertises an object with a required `const` string field, while runtime validation rejects the intended literal string result. Fresh evidence beyond the earlier schema-disambiguation finding is this collision between a valid `const` value and the shorthand token vocabulary; preserve explicit JSON Schema semantics for such values or provide an unambiguous schema discriminator.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `eb3ed02738`\n \n\n

ℹ️ About Codex in GitHub

\nFixed in 0859d5e5 with the discriminator option you suggested.\n\n`$schema` on the output schema turns off shorthand interpretation for the whole tree, so `{\"$schema\": \"https://json-schema.org/draft/2020-12/schema\", \"const\": \"string\"}` validates the literal string `\"string\"` and advertises the const to the model. It is set once for the document rather than guessed per node, and the marker is stripped from the advertised `done_json` parameter since it describes the document, not the argument.\n\nI left the unmarked tie-break as shorthand rather than flipping it, so the earlier disambiguation stays fixed — the ambiguity is now resolvable by the caller in either direction instead of one reading being unreachable.\n\nWorth noting one asymmetry is deliberate and unchanged: `const` is not enforced at the argument gate, so a wrong literal is rejected by `validateCloudOutput` (with its repair attempt) rather than by `validateToolArguments`. That is the same fail-open split described earlier for the composition keywords — the gate refuses undeclared and mistyped arguments, the cloud validator owns the contract.\nAccepted as a known limit rather than fixed, and the repo owner made that call after I laid out the options. Documented rather than left implicit — 0859d5e5.\n\nYour principle is right: enforcement should not depend on model compliance. The problem is that full independence from it costs the feature. Blanking clarification free text is the only option that actually delivers the guarantee, and it makes a strict run unanswerable — the caller has to read the question to answer it, and this suite's driver matches on that text. Harvesting secret-shaped literals out of raw page reads (long digit runs, high-entropy tokens) would catch the inbox-OTP case, but it buys probability rather than a guarantee, at the cost of striking order numbers and identifiers out of legitimate prose.\n\nFor what this actually protects — a disposable Mail.tm inbox, a throwaway signup password, and a one-time code that expires in minutes, published to the operator's own cloud — that trade was not judged worth making. The genuinely valuable secrets in this suite, the CapSolver key and the Gnippets control token, never pass through the model at all.\n\nSo instead of a heuristic, the claim was corrected. `security-model.md` said strict mode \"prevents credential exfiltration even if the model is jailbroken into quoting secrets\" — untrue of the prompt-only implementation that ships today, and still untrue of the redaction layer this branch adds. It now separates the prompt-level rules from what is enforced underneath and names this exact gap. A control that promises less than it delivers is the failure mode worth avoiding here, and that was the real defect behind this finding.\n## Where this stands\n\nSeven commits on top of `70ad5d8e` (19 files, +1385/−72), closing 7 findings from a full review of the branch and 16 review threads raised since. Every thread is answered and resolved.\n\nThe bulk of it is strict-secret handling in the cloud path. That is worth stating plainly: `strictSecretMode` appears **zero times** in `cloud-runs.js` on `main`. Before this branch, a strict-mode cloud run got key-based scrubbing and nothing else — strict mode was prompt-only. So this is the first redaction layer that path has ever had, not a repair of one.\n\n**What it does now.** Strict runs deny by default: tool results reduce to success and HTTP status, tool arguments to the scalar fields grading reads, model prose is replaced. Underneath that, anything the run types into a page, sends in a request body, or reads from a credential-named field is remembered and struck by exact match from everything published afterwards — clarifications, warnings, the final answer, the structured result, and both the bridge and persistence copies. Trace rows take a blunter leaf-type redaction since no caller contract depends on them; the public result keeps what the schema declared.\n\nThe rest: `done_json` could not be called at all for any schema containing a free-form object; combinators were advertised without being evaluated; the smoke job's 120-minute timeout sat under its own 133-minute budget; post-`startRun` failures were reported as provisioning failures; scheduled-job reads and `webbrain_config_result` were unchecked.\n\n## Known remaining risk\n\n1. **Prose-only secrets.** A credential the model reads out of ordinary page text — a one-time code in an inbox message body — is invisible to a redactor that matches known values. If the model repeats it in a clarification, only the prompt stops it. Accepted deliberately: blanking clarification text makes a strict run unanswerable, and entropy-guessing at prose costs false positives. Documented in `security-model.md` under \"Where it stops.\"\n\n2. **The public structured result depends on registration, not type.** A credential the model invents directly in `done_json` and never types, sends, or reads from a labelled field survives in `run.result`. It is still blanked in the trace row. This is the deliberate trade for not returning a result full of placeholders.\n\n3. **`webbrain_config_result` is a guess.** The gate that aborts a scenario whose `session_settings` were not applied accepts several plausible response shapes and treats silence as failure. If provisioning returns no confirmation today, the two scenarios with declared settings will fail rather than run unprotected. Safe direction, but it should be narrowed to the real schema.\n\n4. **Nothing here has run against the live cloud.** Every claim is verified against unit tests and fixtures — 1501 passing in `test/run.js`, plus `test:ci`, `test:security`, and a `--dry-run` over the catalog. The suite itself has never been executed end to end. The first real run is where timeouts, the config gate, and grading under redaction get their actual test.\n\n5. **`$ref` is unsupported** in cloud output schemas and fails closed with a message rather than resolving. A caller using `$defs` will get a validation error, not silence.\n\n6. **Two tests fail on `main` too** — changelog history and the Opera flag license filename. Unrelated to this branch, but they are red in every run.\n\n## Open decisions\n\nWhether strict mode should trade utility for a real guarantee — options were laid out and A (registration-based, what is committed) was chosen for now; C (no model free text at all) is the only one that removes dependence on model compliance, and it breaks the signup scenario as written.\n\nAnd the `webbrain_config_result` shape above, which needs someone who knows the cloud API.\n\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Track post-start errors as scenario failures**\n\nWhen trace export, artifact writing, or Gnippets state retrieval throws after `startRun`, `reachedRunStart` is true and this branch records the error in neither `setupError` nor `scheduledError`. A completed run can therefore still satisfy grading from its run snapshot; if trace export failed, capture download is also skipped while `artifactError` remains null, so even the video check can pass. Preserve a post-start execution/verification error and pass it to `gradeScenario` so these scenarios cannot report a false success.\n\nUseful? React with 👍 / 👎.\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Collect numeric secrets under sensitive keys**\n\nIn a strict run, a JSON request or tool result can represent an OTP or PIN numerically, such as `{\"otp\":123456}`, but this collector registers only string-valued sensitive fields and recursion immediately discards the number. If the model later repeats `123456` in a clarification or public terminal result, value redaction does not know it and the secret is published. The fresh path beyond the earlier numeric `done_json` handling is this request/result collector; stringify and register numeric values found under recognized sensitive keys.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the root schema marker in branch checks**\n\nWhen a `$schema`-marked document contains a combinator branch whose JSON Schema is otherwise ambiguous, `matches` starts a fresh validation without the root marker. For example, `{ $schema: \"…\", anyOf: [{ const: \"string\" }, { type: \"boolean\" }] }` incorrectly rejects the valid result `\"string\"` because the first branch is reinterpreted as shorthand requiring an object field named `const`. Carry the document's JSON-Schema-only mode into branch validation rather than rediscovering the branch type independently.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `7912e8f786`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `28324ec5ef`\n \n\n

ℹ️ About Codex in GitHub

\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Register values from credential-labeled form fields**\n\nWhen a strict run calls top-frame `verify_form` on a prefilled credential, the result represents it as sibling fields such as `{name: \"password\", value: \"secret\"}`; this recursion only treats descendants of a sensitive *key* as sensitive, so the `value` is never registered. Although the immediate `verify_form` update is masked, the model received the raw value and can repeat it in a later clarification or terminal result, which is then published unchanged. Fresh evidence beyond the earlier `verify_form` result finding is this sibling-label path through the new value registry; correlate `name`/`type`/`label` with the field's value when collecting secrets.\n\nUseful? React with 👍 / 👎.\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Fail closed for oversized credential request bodies**\n\nWhen a strict `fetch_url` call has a request body over 10,000 characters, this early return skips credential collection entirely. The tool-call body itself is masked, but the model still saw its password/token fields and can quote one later in a clarification or public terminal result; because the value registry never learned it, that later publication is not redacted. Fresh evidence beyond the earlier fetch-body finding is this hard size cutoff; oversized bodies should trigger fail-closed scalar redaction or bounded credential extraction rather than silently disabling protection.\n\nUseful? React with 👍 / 👎.\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Reject unsupported JSON Schema constraints**\n\nWhen an `output_schema` combines a recognized `type` with constraints such as `minItems`, `maxItems`, `pattern`, `minimum`, or `maximum`, this classifies and advertises the whole object as JSON Schema, but `validateCloudOutput` never evaluates those keywords. For example, `[]` passes `{type:\"array\",minItems:3}` and `10` passes `{type:\"number\",maximum:5}`, so `done_json` can complete a cloud run with a result that violates the caller's contract whenever the provider does not enforce the tool schema itself; implement these constraints or reject schemas containing unsupported keywords.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0f7af02940`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact credential-bearing URL path roots**\n\nWhen a strict-secret run calls `fetch_url` with a capability URL whose first path segment is itself a secret (for example, `https://files.example/`), this preserves that segment verbatim in the published `tool_call` update. `rememberStrictSecrets` also does not register values embedded in `args.url`, so URL credentials cannot be removed from later clarification or terminal text either. Avoid publishing arbitrary path segments in strict mode, or first detect and register credential-bearing URL components.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0f7af02940`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the caller's additionalProperties default**\n\nWhen a JSON Schema object declares `properties` but omits `additionalProperties`, JSON Schema permits extra keys by default; however, passing the generated `done_json` tool through `closeToolDefinitions` recursively adds `additionalProperties: false` to the caller's result schema. A result such as `{name: \"x\", extra: 1}` therefore passes `validateCloudOutput` against `{type: \"object\", properties: {name: {type: \"string\"}}}` but is rejected by `validateToolArguments` before runtime validation, so preserve explicit caller semantics rather than closing these embedded output-schema nodes.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Count Unicode characters consistently in done_json**\n\nWhen the forwarded output schema uses `minLength` or `maxLength` and a result contains an astral Unicode character, the two validators disagree: `validateCloudOutput` correctly counts code points with `[...item].length`, while `validateToolArguments` counts UTF-16 code units with `value.length`. For example, an emoji is valid under `{type: \"string\", maxLength: 1}` at runtime but the advertised `done_json` argument gate rejects it before dispatch; use the same JSON Schema length semantics in both validators.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `fb6ccb71b1`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Register navigation URLs before terminal redaction**\n\nWhen a strict run follows a credential-bearing capability URL through `navigate`, this collector registers URL components only for `fetch_url`. The generic strict-mode masking hides the `navigate` arguments, but `run.finalUrl` is later value-redacted without knowing that URL and `cloudSnapshot` publishes its full path and query. Unlike the previously addressed `fetch_url` path, the fresh evidence here is that navigation URLs never enter the secret registry; collect URL-bearing arguments from `navigate` and equivalent navigation tools as well.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Apply object keywords only to object instances**\n\nWhen a caller supplies a type-agnostic JSON Schema such as a `$schema`-marked `{properties: {...}}`, `{required: [...]}`, or `{additionalProperties: false}`, JSON Schema requires those keywords to be ignored for non-object instances. This branch instead rejects every scalar with `expected object with properties`; for example, the valid string result for `{$schema: \"…\", properties: {a: {type: \"string\"}}}` is rejected and can exhaust the run's single repair attempt. Evaluate these keywords only when `item` is an object and let an explicit `type: \"object\"` enforce objectness.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0382cecaa0`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Recognize verification-code fields in strict request bodies**\n\nWhen a strict run sends an OTP through `fetch_url` as `{\"verification_code\":123456}` or `{\"code\":123456}`, this parsed-body walk passes it to `collectSensitiveStrings`, but `isSensitiveCloudKey` recognizes neither normalized key, so the literal never enters the run's secret registry. The immediate call is masked, but a later clarification, unstructured terminal response, or public `done_json` result can publish `123456` unchanged. Fresh evidence beyond the earlier numeric-secret finding is this common request-body label path; extend the credential-key detector or fail closed for unrecognized scalar body fields.\n\nUseful? React with 👍 / 👎.\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Recognize type-agnostic JSON Schema constraints**\n\nWhen a caller supplies a valid type-agnostic schema such as `{minLength: 3}` without the optional `$schema` or `type`, this detector returns false because the supported constraint keywords are absent from `JSON_SCHEMA_KEYWORD_SHAPES`. Validation then treats the document as shorthand and rejects even `\"abc\"` with `expected object`; boolean `items` and boolean combinator branches are misclassified similarly. Fresh evidence beyond the earlier constraint finding is that the implemented constraints are reachable only after this incomplete classification, so recognize their schema-shaped values here.\n\nUseful? React with 👍 / 👎.\n\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `5a125a3941`\n \n\n

ℹ️ About Codex in GitHub

\n@codex pls review\n\n### 💡 Codex Review\n\nhttps://github.com/esokullu/webbrain/blob/3c0b5b2e1db11711165761a6c4d61179a211a36a/src/chrome/src/cloud-runs.js#L939-L941\n**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve a false root output schema**\n\nWhen a caller supplies the valid JSON Schema boolean `false`, this `||` chain converts it to `null`. The agent therefore receives no `done_json` tool, and the controller can report an ordinary prose completion instead of a structured run that necessarily fails validation. Use presence/nullish checks rather than truthiness so boolean root schemas retain their JSON Schema semantics.\n \n\n

ℹ️ About Codex in GitHub

ℹ️ About Codex in GitHub

","@codex pls review","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `5a125a3941`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Recognize type-agnostic JSON Schema constraints**\n\nWhen a caller supplies a valid type-agnostic schema such as `{minLength: 3}` without the optional `$schema` or `type`, this detector returns false because the supported constraint keywords are absent from `JSON_SCHEMA_KEYWORD_SHAPES`. Validation then treats the document as shorthand and rejects even `\"abc\"` with `expected object`; boolean `items` and boolean combinator branches are misclassified similarly. Fresh evidence beyond the earlier constraint finding is that the implemented constraints are reachable only after this incomplete classification, so recognize their schema-shaped values here.\n\nUseful? React with 👍 / 👎.","src/chrome/src/agent/cloud-output.js",90,"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Recognize verification-code fields in strict request bodies**\n\nWhen a strict run sends an OTP through `fetch_url` as `{\"verification_code\":123456}` or `{\"code\":123456}`, this parsed-body walk passes it to `collectSensitiveStrings`, but `isSensitiveCloudKey` recognizes neither normalized key, so the literal never enters the run's secret registry. The immediate call is masked, but a later clarification, unstructured terminal response, or public `done_json` result can publish `123456` unchanged. Fresh evidence beyond the earlier numeric-secret finding is this common request-body label path; extend the credential-key detector or fail closed for unrecognized scalar body fields.\n\nUseful? React with 👍 / 👎.",470,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0382cecaa0`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Apply object keywords only to object instances**\n\nWhen a caller supplies a type-agnostic JSON Schema such as a `$schema`-marked `{properties: {...}}`, `{required: [...]}`, or `{additionalProperties: false}`, JSON Schema requires those keywords to be ignored for non-object instances. This branch instead rejects every scalar with `expected object with properties`; for example, the valid string result for `{$schema: \"…\", properties: {a: {type: \"string\"}}}` is rejected and can exhaust the run's single repair attempt. Evaluate these keywords only when `item` is an object and let an explicit `type: \"object\"` enforce objectness.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Register navigation URLs before terminal redaction**\n\nWhen a strict run follows a credential-bearing capability URL through `navigate`, this collector registers URL components only for `fetch_url`. The generic strict-mode masking hides the `navigate` arguments, but `run.finalUrl` is later value-redacted without knowing that URL and `cloudSnapshot` publishes its full path and query. Unlike the previously addressed `fetch_url` path, the fresh evidence here is that navigation URLs never enter the secret registry; collect URL-bearing arguments from `navigate` and equivalent navigation tools as well.\n\nUseful? React with 👍 / 👎.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `fb6ccb71b1`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Count Unicode characters consistently in done_json**\n\nWhen the forwarded output schema uses `minLength` or `maxLength` and a result contains an astral Unicode character, the two validators disagree: `validateCloudOutput` correctly counts code points with `[...item].length`, while `validateToolArguments` counts UTF-16 code units with `value.length`. For example, an emoji is valid under `{type: \"string\", maxLength: 1}` at runtime but the advertised `done_json` argument gate rejects it before dispatch; use the same JSON Schema length semantics in both validators.\n\nUseful? React with 👍 / 👎.","src/chrome/src/agent/tools.js",1386,"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the caller's additionalProperties default**\n\nWhen a JSON Schema object declares `properties` but omits `additionalProperties`, JSON Schema permits extra keys by default; however, passing the generated `done_json` tool through `closeToolDefinitions` recursively adds `additionalProperties: false` to the caller's result schema. A result such as `{name: \"x\", extra: 1}` therefore passes `validateCloudOutput` against `{type: \"object\", properties: {name: {type: \"string\"}}}` but is rejected by `validateToolArguments` before runtime validation, so preserve explicit caller semantics rather than closing these embedded output-schema nodes.\n\nUseful? React with 👍 / 👎.",1503,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0f7af02940`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact credential-bearing URL path roots**\n\nWhen a strict-secret run calls `fetch_url` with a capability URL whose first path segment is itself a secret (for example, `https://files.example/`), this preserves that segment verbatim in the published `tool_call` update. `rememberStrictSecrets` also does not register values embedded in `args.url`, so URL credentials cannot be removed from later clarification or terminal text either. Avoid publishing arbitrary path segments in strict mode, or first detect and register credential-bearing URL components.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Reject unsupported JSON Schema constraints**\n\nWhen an `output_schema` combines a recognized `type` with constraints such as `minItems`, `maxItems`, `pattern`, `minimum`, or `maximum`, this classifies and advertises the whole object as JSON Schema, but `validateCloudOutput` never evaluates those keywords. For example, `[]` passes `{type:\"array\",minItems:3}` and `10` passes `{type:\"number\",maximum:5}`, so `done_json` can complete a cloud run with a result that violates the caller's contract whenever the provider does not enforce the tool schema itself; implement these constraints or reject schemas containing unsupported keywords.\n\nUseful? React with 👍 / 👎.",88,"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Fail closed for oversized credential request bodies**\n\nWhen a strict `fetch_url` call has a request body over 10,000 characters, this early return skips credential collection entirely. The tool-call body itself is masked, but the model still saw its password/token fields and can quote one later in a clarification or public terminal result; because the value registry never learned it, that later publication is not redacted. Fresh evidence beyond the earlier fetch-body finding is this hard size cutoff; oversized bodies should trigger fail-closed scalar redaction or bounded credential extraction rather than silently disabling protection.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Register values from credential-labeled form fields**\n\nWhen a strict run calls top-frame `verify_form` on a prefilled credential, the result represents it as sibling fields such as `{name: \"password\", value: \"secret\"}`; this recursion only treats descendants of a sensitive *key* as sensitive, so the `value` is never registered. Although the immediate `verify_form` update is masked, the model received the raw value and can repeat it in a later clarification or terminal result, which is then published unchanged. Fresh evidence beyond the earlier `verify_form` result finding is this sibling-label path through the new value registry; correlate `name`/`type`/`label` with the field's value when collecting secrets.\n\nUseful? React with 👍 / 👎.",290,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `28324ec5ef`\n \n\n

ℹ️ About Codex in GitHub

","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `7912e8f786`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the root schema marker in branch checks**\n\nWhen a `$schema`-marked document contains a combinator branch whose JSON Schema is otherwise ambiguous, `matches` starts a fresh validation without the root marker. For example, `{ $schema: \"…\", anyOf: [{ const: \"string\" }, { type: \"boolean\" }] }` incorrectly rejects the valid result `\"string\"` because the first branch is reinterpreted as shorthand requiring an object field named `const`. Carry the document's JSON-Schema-only mode into branch validation rather than rediscovering the branch type independently.\n\nUseful? React with 👍 / 👎.",332,"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Collect numeric secrets under sensitive keys**\n\nIn a strict run, a JSON request or tool result can represent an OTP or PIN numerically, such as `{\"otp\":123456}`, but this collector registers only string-valued sensitive fields and recursion immediately discards the number. If the model later repeats `123456` in a clarification or public terminal result, value redaction does not know it and the secret is published. The fresh path beyond the earlier numeric `done_json` handling is this request/result collector; stringify and register numeric values found under recognized sensitive keys.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Track post-start errors as scenario failures**\n\nWhen trace export, artifact writing, or Gnippets state retrieval throws after `startRun`, `reachedRunStart` is true and this branch records the error in neither `setupError` nor `scheduledError`. A completed run can therefore still satisfy grading from its run snapshot; if trace export failed, capture download is also skipped while `artifactError` remains null, so even the video check can pass. Preserve a post-start execution/verification error and pass it to `gradeScenario` so these scenarios cannot report a false success.\n\nUseful? React with 👍 / 👎.","ci/run.mjs","## Where this stands\n\nSeven commits on top of `70ad5d8e` (19 files, +1385/−72), closing 7 findings from a full review of the branch and 16 review threads raised since. Every thread is answered and resolved.\n\nThe bulk of it is strict-secret handling in the cloud path. That is worth stating plainly: `strictSecretMode` appears **zero times** in `cloud-runs.js` on `main`. Before this branch, a strict-mode cloud run got key-based scrubbing and nothing else — strict mode was prompt-only. So this is the first redaction layer that path has ever had, not a repair of one.\n\n**What it does now.** Strict runs deny by default: tool results reduce to success and HTTP status, tool arguments to the scalar fields grading reads, model prose is replaced. Underneath that, anything the run types into a page, sends in a request body, or reads from a credential-named field is remembered and struck by exact match from everything published afterwards — clarifications, warnings, the final answer, the structured result, and both the bridge and persistence copies. Trace rows take a blunter leaf-type redaction since no caller contract depends on them; the public result keeps what the schema declared.\n\nThe rest: `done_json` could not be called at all for any schema containing a free-form object; combinators were advertised without being evaluated; the smoke job's 120-minute timeout sat under its own 133-minute budget; post-`startRun` failures were reported as provisioning failures; scheduled-job reads and `webbrain_config_result` were unchecked.\n\n## Known remaining risk\n\n1. **Prose-only secrets.** A credential the model reads out of ordinary page text — a one-time code in an inbox message body — is invisible to a redactor that matches known values. If the model repeats it in a clarification, only the prompt stops it. Accepted deliberately: blanking clarification text makes a strict run unanswerable, and entropy-guessing at prose costs false positives. Documented in `security-model.md` under \"Where it stops.\"\n\n2. **The public structured result depends on registration, not type.** A credential the model invents directly in `done_json` and never types, sends, or reads from a labelled field survives in `run.result`. It is still blanked in the trace row. This is the deliberate trade for not returning a result full of placeholders.\n\n3. **`webbrain_config_result` is a guess.** The gate that aborts a scenario whose `session_settings` were not applied accepts several plausible response shapes and treats silence as failure. If provisioning returns no confirmation today, the two scenarios with declared settings will fail rather than run unprotected. Safe direction, but it should be narrowed to the real schema.\n\n4. **Nothing here has run against the live cloud.** Every claim is verified against unit tests and fixtures — 1501 passing in `test/run.js`, plus `test:ci`, `test:security`, and a `--dry-run` over the catalog. The suite itself has never been executed end to end. The first real run is where timeouts, the config gate, and grading under redaction get their actual test.\n\n5. **`$ref` is unsupported** in cloud output schemas and fails closed with a message rather than resolving. A caller using `$defs` will get a validation error, not silence.\n\n6. **Two tests fail on `main` too** — changelog history and the Opera flag license filename. Unrelated to this branch, but they are red in every run.\n\n## Open decisions\n\nWhether strict mode should trade utility for a real guarantee — options were laid out and A (registration-based, what is committed) was chosen for now; C (no model free text at all) is the only one that removes dependence on model compliance, and it breaks the signup scenario as written.\n\nAnd the `webbrain_config_result` shape above, which needs someone who knows the cloud API.\n","Accepted as a known limit rather than fixed, and the repo owner made that call after I laid out the options. Documented rather than left implicit — 0859d5e5.\n\nYour principle is right: enforcement should not depend on model compliance. The problem is that full independence from it costs the feature. Blanking clarification free text is the only option that actually delivers the guarantee, and it makes a strict run unanswerable — the caller has to read the question to answer it, and this suite's driver matches on that text. Harvesting secret-shaped literals out of raw page reads (long digit runs, high-entropy tokens) would catch the inbox-OTP case, but it buys probability rather than a guarantee, at the cost of striking order numbers and identifiers out of legitimate prose.\n\nFor what this actually protects — a disposable Mail.tm inbox, a throwaway signup password, and a one-time code that expires in minutes, published to the operator's own cloud — that trade was not judged worth making. The genuinely valuable secrets in this suite, the CapSolver key and the Gnippets control token, never pass through the model at all.\n\nSo instead of a heuristic, the claim was corrected. `security-model.md` said strict mode \"prevents credential exfiltration even if the model is jailbroken into quoting secrets\" — untrue of the prompt-only implementation that ships today, and still untrue of the redaction layer this branch adds. It now separates the prompt-level rules from what is enforced underneath and names this exact gap. A control that promises less than it delivers is the failure mode worth avoiding here, and that was the real defect behind this finding.",860,"Fixed in 0859d5e5 with the discriminator option you suggested.\n\n`$schema` on the output schema turns off shorthand interpretation for the whole tree, so `{\"$schema\": \"https://json-schema.org/draft/2020-12/schema\", \"const\": \"string\"}` validates the literal string `\"string\"` and advertises the const to the model. It is set once for the document rather than guessed per node, and the marker is stripped from the advertised `done_json` parameter since it describes the document, not the argument.\n\nI left the unmarked tie-break as shorthand rather than flipping it, so the earlier disambiguation stays fixed — the ambiguity is now resolvable by the caller in either direction instead of one reading being unreachable.\n\nWorth noting one asymmetry is deliberate and unchanged: `const` is not enforced at the argument gate, so a wrong literal is rejected by `validateCloudOutput` (with its repair attempt) rather than by `validateToolArguments`. That is the same fail-open split described earlier for the composition keywords — the gate refuses undeclared and mistyped arguments, the cloud validator owns the contract.",52,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `eb3ed02738`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Accept const values that resemble shorthand tokens**\n\nWhen a caller supplies the valid JSON Schema `{ \"const\": \"string\" }`, this predicate treats `\"string\"` as a shorthand type token and therefore classifies the whole schema as shorthand. `done_json` then advertises an object with a required `const` string field, while runtime validation rejects the intended literal string result. Fresh evidence beyond the earlier schema-disambiguation finding is this collision between a valid `const` value and the shorthand token vocabulary; preserve explicit JSON Schema semantics for such values or provide an unambiguous schema discriminator.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact secrets first observed in page text**\n\nWhen an OTP or token first appears only in ordinary inbox/page text and the model repeats it in a later clarification, `collectSensitiveStrings` records nothing because it only recognizes values beneath sensitive-looking keys. The `clarify` update and `pendingInput` can therefore publish the literal secret despite strict mode. Fresh evidence beyond the earlier clarification finding is the newly committed known-limit path immediately above this call, which explicitly leaves page-body OTPs dependent on the prompt; strict-secret enforcement should not rely on model compliance.\n\nUseful? React with 👍 / 👎.","@codex pls check","Fixed in eb3ed027, and you are right that this was an over-correction on my side one commit earlier. Redacting the public result by leaf type satisfied strict mode by making the run useless: `completed`, with every string and number replaced by a placeholder.\n\nTook your first option. The two consumers want different things, so they now get different redactors. The update row is trace and persistence with no contract to honour and keeps the blunt leaf-type redaction. `run.result` and `run.summary` are the caller's answer, so they take value redaction — registered credentials struck, everything the schema declared left intact. `{name: \"item\", count: 3}` comes back as itself.\n\nThe case behind the previous finding stays closed because the value redactor now also matches a number against a registered secret's string form: an OTP typed as text and returned as `verification_code: 481920` is struck, while `count: 3` is not. That does mean the public result depends on registration rather than on type — a credential the model invents in the result and never types or exposes under a sensitive key would survive there, though it is still blanked in the trace row. That is the trade I took over returning placeholders; the alternative you offered — rejecting string and numeric fields in strict output contracts outright — is a bigger product decision and I have flagged it to the repo owner rather than making it unilaterally.\n\n`run.summary` moved to value redaction too, so it stops being the one terminal field playing by different rules.","Fixed in eb3ed027. The collector only looked at text-entry arguments, so a credential that is minted but never typed was invisible to it — and that is precisely the Mail.tm flow, where the account password is created inside the `POST /accounts` body and never touches a form field.\n\nSensitive-keyed values in any tool call's arguments are registered now, and the request body is parsed as JSON or form encoding to reach the ones nested inside it. Verified end to end on that flow: the password is struck from the later clarification, from the done_json summary, and from the persisted rows, without ever having been typed.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Remember credentials embedded in strict fetch bodies**\n\nWhen a strict run generates a credential only inside a mutating `fetch_url` body, this collector never records it because tool calls are inspected only for text-entry tools. In the new Mail.tm scenario, the disposable-account password is created in the JSON body of `POST /accounts`; although that body update is hidden, a later `clarify` payload quoting the password is retained and published because value redaction does not know it. Fresh evidence beyond the earlier clarification finding is this untracked API-body credential path; parse or otherwise register sensitive fetch-body values before discarding the arguments.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Preserve schema-valid values in strict run results**\n\nFor any strict cloud run whose `output_schema` contains legitimate string or numeric fields, this assigns the redacted `cloudResult` to the public `run.result`, so a successfully validated value such as `{name:\"item\", count:3}` is returned as placeholders while the run still reports `completed`. Fresh evidence beyond the earlier string-result finding is that the new leaf redactor now replaces both strings and numbers before this assignment; keep the schema-valid public result intact while sanitizing only persistence/trace data, or make strict output contracts explicitly reject those types.\n\nUseful? React with 👍 / 👎.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `a1dfec9ea6`\n \n\n

ℹ️ About Codex in GitHub

","Fixed in a1dfec9e. Numbers are redacted alongside strings now.\n\nThis one my own review walked past, and worse: when I routed `run.result` through this redactor earlier in the branch I described preserving numbers as a *feature*, because scenario grading reads outcome flags. It is both — and I only checked the half that helped me.\n\nBooleans and null still survive, since neither can encode a credential and a `true` outcome flag is what grading asserts on. The consequence is that a strict run's structured output is assertable on booleans only, which is now stated in the source; the signup scenario's five checks are all booleans, and it still grades 100.\n\nYour secondary point is the sharper one and is covered: the `done_json` `tool_call` is published before argument validation can reject it, so the args are a publication path in their own right. The new fixture asserts through the call args, the result, and `run.result`, over every JSON leaf type — number, string, nested array of numbers, boolean, false, null — in both the snapshot and the persisted rows.","Fixed in a1dfec9e.\n\nAll four terminal fields — `content`, `result`, `finalUrl`, `error` — now go through the run's value redaction, structured or not, rather than only the structured branch. `finalUrl` was worth including for the same reason: a confirmation URL can carry a token in a query parameter.\n\nI chose value redaction over blanking. With no output schema that final text *is* the result, so blanking would leave the run with nothing; instead the answer comes back readable with the literal struck (`\"Signup finished. The code was [redacted strict value].\"`). That option only became available once b338fd0a added value-based redaction — blanking really was the only alternative before it.\n\nSame documented limit applies as for clarifications: a secret the model reads out of ordinary prose and never types is not registered, so it still rests on the strict prompt. Everything typed, or surfaced under a key the scrubber knows, is struck.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `b338fd0a11`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact numeric secrets in structured payloads**\n\nThis strict-mode redactor replaces only string leaves, so a model that serializes a six-digit OTP as a number—such as `verification_code: 123456`—publishes it unchanged in the `done_json` call/result update. This also occurs on an invalid `done_json` attempt because `tool_call` is emitted before the argument-rejection result, and neither the later known-string replacement nor key scrubber recognizes a generic `verification_code` numeric value; redact numeric credential values as well or suppress the structured payload entirely.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact terminal output for unstructured strict runs**\n\nWhen `strictSecretMode` is enabled without an `output_schema`, this conditional takes the raw-content branch, and the same content is subsequently assigned to `run.result`. Unlike the previously fixed update rows, these run-level `content` and `result` fields are returned over the bridge and persisted, so a final response that repeats a password, token, or OTP still escapes strict mode; apply strict redaction to terminal fields regardless of whether the run is structured.\n\nUseful? React with 👍 / 👎.","Fixed in b338fd0a. Setup now ends where it actually ends: a `reachedRunStart` flag is set once `startRun` returns a run id, and the catch only assigns `setupError` before that point.\n\nWith `setupError` unset, `inferStuckAt` reads the run instead of short-circuiting, so a timeout returns `execution` (or `planning`/`navigation`, depending on what the updates show), a trace-export failure after a completed run falls through to `verification`, and provisioning failures still report `setup`. The error artifact is written either way, so nothing is lost from the report. Three cases added to `ci/test.mjs`.","Fixed in b338fd0a. This one was mine and it was avoidable — I fixed deep equality in `validateCloudOutput` and left `validateToolArguments` on `Object.is`, after twice writing that the two validators have to agree on any schema they both see.\n\nBoth now import one exported `jsonDeepEqual`. And rather than fix the next instance when it is reported, the test is now a sweep: fourteen schema/result pairs covering enum (scalar, object, array), const, nullable optionals, free-form objects, shorthand, and closed schemas, asserting the gate and the cloud validator return the same verdict for each, in both trees. `const` stays unenforced at the gate deliberately — failing open there and enforcing in the cloud validator is the split I described earlier for the combinators.","Fixed in b338fd0a, and I changed approach rather than adding another carve-out.\n\nYou are right that the prompt is not a redaction boundary. But enumerating update types is what produced this finding and the two before it — each round redacted the types someone had thought of, and `clarify` was simply the last one left. So strict runs now redact by *value*: whatever the run types into a page, plus any value sitting under a key the scrubber already treats as sensitive, is remembered and struck from the text of every later update. Clarifications, warnings, captcha diagnostics, and anything added to this file later are covered without being named. The literals live in a map outside the run object so they cannot reach session storage, and are dropped when the run ends.\n\nThe clarification stays answerable, which was your constraint: `clarifyId`, `options`, and the question survive, with the secret replaced by `[redacted strict value]`. The CI driver regex-matches that question and still does.\n\nOne limit is now explicit in the source instead of undiscovered: a secret the model only ever *reads* out of an ordinary field — an OTP in the body text of an inbox message, not under a key named `otp` — never reaches this code in a recognizable form, so a clarification quoting it still rests on the prompt boundary alone. Closing that means either blanking clarification text, which makes a strict run unanswerable, or guessing at entropy in prose. I took the documented limit over either.\n\nVerified by emitting all fifteen update types with an embedded secret and asserting it appears in neither the snapshot nor the persisted rows.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `7cce77cccc`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the main-run failure stage**\n\nWhen `waitForRunWithClarifications` times out, it supplies the latest active run through `error.latest`, but this catch still assigns the error to `setupError`; `inferStuckAt` then returns `setup` before inspecting that run's updates. Trace-export and Gnippets-verification failures are similarly mislabeled, so execution or verification failures in the smoke report appear as provisioning failures even though scheduled failures now retain their own stage.\n\nUseful? React with 👍 / 👎.","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve structural equality for object enum results**\n\nWhen an output schema contains an object- or array-valued `enum`, spreading it into the `done_json` argument schema sends the separately parsed model value through `validateToolArguments`, whose enum check uses `Object.is`. A structurally identical value therefore fails at the argument gate before `validateCloudOutput` can apply its new deep-equality logic, making such a valid cloud output impossible to submit; the argument validator must use the same structural comparison.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact clarification payloads in strict mode**\n\nWhen a strict cloud run asks for clarification after reading or generating a credential, this carve-out publishes the raw `question`, `options`, and `reason` and stores the same payload in `pendingInput`. If the model repeats an OTP, token, or password in that clarification, the key-based scrubber will not recognize it and the secret is persisted remotely; prompt instructions are not a sufficient redaction boundary, so sanitize the payload while retaining a safe question for the caller.\n\nUseful? React with 👍 / 👎.","Fixed in 7cce77cc. `const` uses structural equality now — key-order independent, recursive through objects and arrays.\n\n`enum` had the identical defect (`Array.prototype.includes` is SameValueZero, so an object member could never match either) and is fixed in the same change, since it would have been the next comment.","Fixed in 7cce77cc — and you are right that this repeated the exact bug the change was meant to fix. I dropped `description`/`required`/`additionalProperties` as signals because they are ordinary field names, then added `const`/`anyOf`/`$ref` and friends by name alone, which are equally ordinary field names.\n\nA keyword now has to carry a schema-shaped value: `properties` a plain object, `items` an object or array, `enum` an array, and the composition keywords a non-empty array whose every element is an object. `const` and `$ref` take free values, so the tell there is that a shorthand type token (`string`, `string[]`, `number?`) is never what a caller means by `{const: \"ok\"}` or `{$ref: \"#/$defs/x\"}` — which resolves your `{const: \"string\"}` example while keeping `{const: \"ok\"}` and nested `{status: {const: \"ok\"}}` working.\n\nI kept `const` as a classifier rather than dropping it: a bare `{const: \"ok\"}` appears as a child of a `properties` map all the time, and classifying that as shorthand would break the common case to fix the rare one.\n\nTested both directions in `test/run.js` — eight shorthand shapes that must not classify, seven schema shapes that must, and an end-to-end check that `{const: \"string\"}` is validated and advertised as shorthand, required field and all.","Fixed in 7cce77cc. Good catch — `createIncognitoBrowser` has been surfacing `webbrain_config_result` all along and nothing read it, which made the redaction work in the preceding commits conditional on a setting nobody verified.\n\nA scenario that declares `session_settings` now aborts before `startRun` unless provisioning confirms every one of them. I applied it to any scenario with declared settings rather than only sensitive ones: if `scheduledRequireConsequentialConfirmation` silently failed to apply, that scenario's result is not meaningful either.\n\nOne caveat worth stating plainly: the cloud's response schema for `webbrain_config_result` is not in this repo, so `unappliedSessionSettings` accepts the shapes it plausibly takes — an echoed `settings` object (preferred, since it confirms the value and not just the key), an `applied` list, or any of the usual `ignoredKeys`/`rejected`/`unsupported`/`failed` lists — and treats silence as failure. That is the fail-closed direction you asked for, but it does mean that if provisioning returns nothing today, the two scenarios with declared settings will fail rather than run unprotected. That seemed like the right way to be wrong. If the real response shape is known, narrowing this to it would be strictly better.\n\nThe abort happens inside the existing `try`, so the `finally` still destroys the session — no leak. Nine unit cases in `ci/test.mjs` pin each way provisioning can decline, plus silence.",208,"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Disambiguate shorthand fields from schema keywords**\n\nWhen a shorthand output schema has an ordinary field named `const`, `anyOf`, `oneOf`, `allOf`, or `$ref` (for example `{const: 'string'}`), this detector now classifies the whole object as JSON Schema instead of the documented shorthand form. Validation then either rejects the intended object or silently skips its required field, and `doneJsonResultSchema` advertises the same incorrect contract; require schema-shaped keyword values or an explicit schema marker before changing interpretation.\n\nUseful? React with 👍 / 👎.","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Compare JSON Schema const values structurally**\n\nWhen a caller uses an object or array as a JSON Schema `const`, the model's `done_json` argument is a separately parsed value, so `Object.is` can never match it even when its JSON structure is identical. Such a valid result is rejected twice and the cloud run fails; apply JSON Schema deep-equality semantics rather than reference identity.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Fail closed when sensitive session settings are rejected**\n\nWhen browser provisioning returns a failed or partial `webbrain_config_result`, this path ignores it and starts the scenario anyway. For `gnippets-signup-otp-disposable`, that can leave `strictSecretMode` at its default `false` while the run handles a password, mailbox token, and OTP, allowing raw updates to be published remotely; inspect the returned configuration result and abort before starting any sensitive run unless all required settings were applied.\n\nUseful? React with 👍 / 👎.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `6cb5c65a73`\n \n\n

ℹ️ About Codex in GitHub

","Fixed in 6cb5c65a, taking your first option — the generated type now includes `null`.\n\nWidening the advertised type is the safer of the two: `validateCloudOutput` has accepted an explicit null for optional shorthand all along, so tightening it instead would change behavior for existing callers. `nickname: \"string?\"` now advertises `{\"type\":[\"string\",\"null\"]}` and `tags: \"string[]?\"` becomes `{\"type\":[\"array\",\"null\"],\"items\":{\"type\":\"string\"}}`. A field declared `any` already permitted null and is left alone.\n\nThis is the same advertised-stricter-than-enforced asymmetry as the free-form-object bug, just pointing the other way, so the new test asserts the two validators agree rather than checking either in isolation. It also pins that widening does not slacken the declared type: `nickname: 42` is still rejected.",1342,"Fixed in 6cb5c65a — and you are right that this one was a regression I introduced, not a pre-existing gap. Before the change an unrecognized combinator fell through to the shorthand branch and got rejected (for the wrong reason, but rejected); after it, `{anyOf:[{type:\"string\"},{type:\"boolean\"}]}` classified as JSON Schema and validated `7` clean.\n\nImplemented rather than rejected, since callers legitimately use these: `const`, `anyOf`, `oneOf` (exactly-one), and `allOf` are evaluated via a nested `validateCloudOutput` call so a branch check does not pollute the caller's error list. `$ref` is reported as unsupported instead — resolving it properly needs a `$defs` resolver, and failing closed with a clear message beats silently publishing an unvalidated result.\n\n`validateValue` in `tool-arguments.js` is permissive on these keywords, which is the right split: it fails open on what it does not understand, and `validateCloudOutput` enforces the contract. So no false rejection at the argument gate.\n\nTen combinator cases added to `test/run.js`, run against both trees; they fail on d27ee256.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `d27ee256e0`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve nullable semantics for optional shorthand fields**\n\nWhen an optional shorthand property is explicitly `null`, such as `{nickname: 'string?'}`, `validateCloudOutput` accepts it, but this converter strips `?` and advertises only `{type:'string'}`. `validateToolArguments` consequently rejects the `done_json` call before runtime validation, even though the output is valid under the supplied shorthand schema; include `null` in the generated type or stop treating `null` as valid for optional shorthand fields.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Validate every advertised JSON Schema combinator**\n\nWhen a cloud caller supplies an `output_schema` using `const`, `anyOf`, `oneOf`, `allOf`, or `$ref`, this change classifies it as JSON Schema, but `validateCloudOutput` never evaluates those keywords. For example, `7` against `{anyOf:[{type:'string'},{type:'boolean'}]}` returns `ok: true`, so `done_json` can mark the run completed and publish a result that violates the caller's contract; either implement these keywords or reject them as unsupported.\n\nUseful? React with 👍 / 👎.","Fixed in d27ee256.\n\nYour arithmetic matches mine — I get ~133 min for the pack serially (5 × 10 min `waitForBrowser` = 50, plus preload/run/scheduled budgets and the 2-minute buffers), against a 120-minute job.\n\nRaised to 150, and `.github/workflows/cloud-e2e.yml` to 330 since manual dispatch can pick `--pack all --concurrency 1` (~305 min). Rather than another literal that drifts, `ci/test.mjs` now derives the bound from the catalog and asserts each workflow covers the widest pack it can run, so adding a scenario fails the test instead of quietly shrinking the margin.\n\nAlso fixed the harm behind the finding: a killed job skips every `finally`, so `ci/run.mjs` now tracks in-flight browser sessions and Gnippets fixtures and releases them on SIGINT/SIGTERM/SIGHUP. Separately, `waitForRunWithClarifications` was restarting the full timeout after every answered clarification (five questions on a 10-minute scenario licensed 72 minutes) — it uses one shared deadline now, which also tightens the worst case above.",".github/workflows/webbrain-cloud-smoke.yml","Fixed in d27ee256.\n\nStrict mode redacted a list of known-risky tools and let everything else through, which was the wrong shape — the same OTP comes back out of `get_accessibility_tree`/`read_page` too, not just prose. It now denies by default: `text`/`text_delta` content is replaced, `error`/`run_status` drop their `message` (which carries the model's final response), non-`done_json`/`verify_form` tool results reduce to `success` + HTTP status, and tool args to the scalar keys grading reads. The consecutive-delta branch you flagged now routes through `cloudSafeUpdateData` instead of appending raw content onto the stored row.\n\n`clarify` is the one deliberate carve-out — a caller has to read the question to answer it — and that is commented in the source.\n\nCovered by a new fixture in `ci/cloud-capture.test.mjs` that publishes an OTP through page reads, streamed and final prose, a script argument, and the structured result, then asserts it appears in neither the snapshot nor the persisted rows. It fails against the pre-fix code.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `70ad5d8e3a`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Raise the timeout above the serial smoke budget**\n\nEven after the earlier timeout finding prompted an increase to 120 minutes, the `smoke` job still runs `cloud-smoke` serially: the five scenarios can occupy about 83 minutes across their preload, main-run, scheduled-job, and two-minute wait buffers, and `waitForBrowser` permits another 50 minutes across five sessions. Thus slow-but-bounded execution can exceed the job limit before accounting for installation, tests, artifact writing, and cleanup, causing GitHub Actions to terminate the process before the report and cleanup complete; increase the timeout further or parallelize the pack.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact strict-mode text updates before persistence**\n\nFresh evidence beyond the prior `done_json` comment is that strict sanitization is applied only to selected tool updates: ordinary `text` and `text_delta` updates fall through `cloudSafeUpdateData` unchanged, while consecutive deltas return before this call entirely. When a streaming provider emits prose alongside a tool call, a password or OTP repeated in that prose remains in `run.updates` and is persisted/published even though the corresponding `done_json` call and result are redacted; redact or suppress textual updates for strict-secret runs as well.\n\nUseful? React with 👍 / 👎.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `16d19db85b`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Trigger smoke tests for background bridge changes**\n\nWhen a push changes only `src/chrome/src/background.js`, this path filter skips the workflow even though the new `cloud_scheduled_jobs` bridge handler is implemented there and is required by the Google Forms smoke scenario. Include `src/chrome/src/background.js` so regressions in that handler are exercised on `main`.\n\nUseful? React with 👍 / 👎.",15,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `29d09b892d`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Preserve non-secret strings in strict structured results**\n\nWhen `strictSecretMode` is enabled for any structured cloud run whose schema contains legitimate text, this replaces every string in `cloudResult` with the same placeholder before `pushUpdate` assigns it to `run.result`. The run can therefore report `completed` while API consumers receive corrupted headlines, URLs, filenames, and other non-secret output; retain the validated result for the public response and sanitize only secret-bearing trace or persistence data.\n\nUseful? React with 👍 / 👎.","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Match scheduled-job URLs that include query parameters**\n\n`waitForScheduledJobs` requests `/scheduled-jobs?job_id=task_1`, so this `endsWith('/scheduled-jobs')` check never matches. The mock then falls through to `JSON.parse(options.body)` for a GET request whose body is undefined, causing `npm run test:ci` to fail before the smoke suite can run; match the URL pathname or the route prefix including its query string.\n\nUseful? React with 👍 / 👎.","ci/test.mjs","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `0cc5619ca9`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Scope scheduled-job reads to managed runs**\n\nWhen the cloud bridge is enabled, the newly allowlisted `cloud_scheduled_jobs` action returns `scheduler.listJobs({ tabId: null })`, which includes every locally stored scheduled job rather than only the job IDs created by the requesting cloud run. These summaries contain target URLs, prompts/results, and clarification state, so a managed sidecar polling two CI jobs can also receive unrelated user task history; require the caller's expected IDs and filter the response to those managed jobs.\n\nUseful? React with 👍 / 👎.","src/chrome/src/background.js","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `38d906722a`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Enforce strict-secret handling in done_json**\n\nWhen `strictSecretMode` is enabled for the new disposable-email/OTP scenario, this structured-output branch bypasses the strict `done` variants below and builds `done_json` without passing the strict flag. Its required `summary` remains an unrestricted string, and both the `done_json` call arguments and terminal summary are published by `cloud-runs.js`; the generic scrubber cannot recognize a password, token, or OTP embedded in prose. Consequently, if the model includes one of the generated credentials in its summary, the value is sent to and persisted by WebBrain Cloud despite strict mode, so use a strict `done_json` definition and/or redact its summary before publishing.\n\nUseful? React with 👍 / 👎.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `44161f0027`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Increase the timeout for serial cloud-smoke runs**\n\nWhen the newly exposed `cloud-smoke` pack is dispatched with the supported concurrency value `1`, its configured execution budgets total about 83 minutes before browser provisioning, `npm ci`, tests, artifact handling, and cleanup: Wikipedia and NYTimes each have preload and main-run waits, Forms adds preload, main-run, and scheduled-job waits, and the remaining two scenarios add their own waits. The workflow's 90-minute job timeout can therefore terminate a valid serial run before `ci/run.mjs` writes the suite report or finishes cleanup. Fresh evidence beyond the earlier dedicated-workflow finding is that this commit adds `cloud-smoke` to this separate manual workflow while it retains the shorter timeout; raise this workflow's timeout or disallow serial execution for this pack.\n\nUseful? React with 👍 / 👎.",".github/workflows/cloud-e2e.yml",12,"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Redact verify_form results in strict cloud runs**\n\nWhen a strict-secret cloud run calls `verify_form`, only `fetch_url` results are sanitized here, so the result falls through unchanged. The top-frame `verify_form` implementation returns every input's literal `el.value`, including password fields; the new `gnippets-signup-otp-disposable` scenario explicitly fills a random password and then requires `verify_form`. Consequently, that password is included in the cloud run updates sent over the bridge and persisted remotely even though the later CI artifact sanitizer removes it. Redact sensitive form field values—or all `verify_form` result values—in strict mode before publishing the update.\n\nUseful? React with 👍 / 👎.",204,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `56e9b3e21b`\n \n\n

ℹ️ About Codex in GitHub

","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `c53cb8c5cd`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Preserve the scheduled-wait failure stage**\n\nWhen the main Google Forms run succeeds but either scheduled job remains nonterminal past `scheduled_timeout_ms`, this rethrow reaches the outer catch and is assigned to `setupError`; `inferStuckAt` then unconditionally reports `setup`. The smoke summary consequently attributes a post-run scheduled-execution timeout to fixture setup, obscuring the actual failure stage; track this error separately as scheduled execution or verification.\n\nUseful? React with 👍 / 👎.",272,"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Validate scheduled job targets and prompts**\n\nFor the Google Forms smoke scenario, these checks accept any two `schedule_task` calls whose jobs later report `completed`/`success`; they never verify the requested Forms URL, the 0/60-second schedules, the distinct A/B prompts, or that the returned IDs match the result fields. A run can therefore pass after scheduling two unrelated successful jobs without exercising either form submission, so retain and grade the scheduled job definitions or the corresponding call arguments.\n\nUseful? React with 👍 / 👎.","ci/catalog/scenarios.json",391,"\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `7885329a55`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Trigger the smoke workflow for cloud bridge changes**\n\nThe changed `src/chrome/src/offscreen/cloud-bridge.js` controls the cloud handshake and now advertises `run_modes_v1`, but none of these push-path entries covers that file. A future bridge-only change can therefore land on `main` without immediately running the cloud smoke pack that depends on the bridge, leaving failures undiscovered until the next scheduled run; include the offscreen bridge path in this filter.\n\nUseful? React with 👍 / 👎.",16,"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Allow the serial smoke pack to reach its configured timeouts**\n\nWith the workflow running `cloud-smoke` at concurrency 1, the four scenarios allow 50 minutes of agent execution alone, because the Wikipedia and NYTimes scenarios each perform a preload run with the same timeout before their main run; `waitForRun` also adds two-minute buffers and browser provisioning and tests consume additional time. When multiple external sites are slow but still within their scenario budgets, this 45-minute job limit terminates Node before it can write the suite report or execute the browser/fixture cleanup in `finally`, so increase the job timeout or run scenarios concurrently.\n\nUseful? React with 👍 / 👎.","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `cd80970f2b`\n \n\n

ℹ️ About Codex in GitHub

","**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Remove capability URLs from sensitive artifacts**\n\nFor the sensitive Gnippets scenario, `final_url` is the high-entropy fixture capability URL derived from `setup.app_url`, but both this sanitizer and `sanitizeRun` retain it verbatim. If fixture deletion fails, the workflow still uploads artifacts via its `if: always()` step, exposing a live bearer-style URL until expiration despite the sensitive-artifact policy; omit the URL or retain only non-capability origin information.\n\nUseful? React with 👍 / 👎.","ci/lib/sanitize.mjs","**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Require successful results for skill and tool checks**\n\nWhen `load_skill` or another required tool is rejected or fails, these checks still pass solely because a matching `tool_call` exists. Although the updated `toolRequests` path now correlates calls with successful results, this fresh evidence shows the `skills` and `tools` loops still do not, so the signup smoke test can report that both skills were loaded and required instrumentation was exercised even when their results have `success: false`; correlate these checks with their `tool_result` records as well.\n\nUseful? React with 👍 / 👎.","ci/lib/grader.mjs","\n### 💡 Codex Review\n\nHere are some automated review suggestions for this pull request.\n\n**Reviewed commit:** `66cfb5347e`\n \n\n

ℹ️ About Codex in GitHub