Codex agent — after remediation

Codex agent remediation result

1. Generated. codex wrote this application during this run, from a prompt. Not written by a human, and not selected for being vulnerable. The prompt and generated code browser are linked below.
2. Insecure. REACHABLE found the remediation list — all findings that are not proven noise. See the scan.
3. Remediated. REACHABLE handed that remediation list to the same agent. The final scan has 7 open actionable finding(s); 0 resolved against the baseline scan.

Application evidence: generation prompt · workspace contents · code before remediation · fixed code · side-by-side code diff

Model disclosure: the application was written by gpt-5.5 from OpenAI API, pinned for this run and recorded in the run's evidence. The fix was made by the same agent, but through reachctl remediate, which selects the agent and does not pin its model — so the fixing model is whichever that agent's CLI resolved at run time, and is not asserted here.

Scanner provenance

REACHABLE wheel/build and scan timestamps, read from the scanner database rows that produced the page. Actionable counts are repo.db SIGNAL rows under the product ACTIONABLE_SQL filter.

Run estimate

Token estimates are recorded before the run starts. The remediation estimate is recalculated after REACHABLE has the scan database and knows how many findings are in scope.

Run 2026-09-12 14:21:45 UTC · status partial after 2 agent fix attempt(s)

Run status: partial after 2 iteration(s).

Initial actionable (repo.db): 7. Resolved (scan delta): 0. Current open (repo.db): 7. Noise (repo.db baseline): 24. INITIAL, OPEN, and RESOLVED come from repo.db actionable counts (product ACTIONABLE_SQL on the baseline and final scans). They are not counted from SARIF, data.json, or remediation-audit row matching. The table below is the per-finding remediation ledger.

Open means still actionable on the final scan in repo.db. That can mean the iteration budget ended, the agent did not make the right change, or the finding needs a non-source/package/build change that the agent could not safely complete in this lane. Per-finding ledger rows below may still disagree with this scan total when matching is incomplete; the cards follow the database.

Generated workspace contents

The agent generated these files in the repository before scan. They are scanned and published as evidence. Dependency installs, build outputs, and compiled binaries can explain why one agent has more package or binary findings than another.

Workspace observations: binary_artifact: 12, build_directory: 1735, compiled_artifact: 9, extensionless_executable: 12. Open the full JSON.

Remediation scope — 7 finding(s)

repo.db actionable count on the baseline scan. Table lists 7 ledger/validation row(s) as per-finding evidence.

This is the remediation list REACHABLE handed to the agent, collapsed to each finding's final recorded outcome. The noise list below is excluded only when REACHABLE has explicit non-production or unreachable evidence.

The code the agent wrote

The staged patch, exactly as committed.

The agent changed no files. The diff was produced and is empty, so this is a measured outcome and is published as such.

Noise — 22 finding(s)

All 22 are excluded for one reason: the application never reaches the vulnerable code. These are real advisories against real dependencies — not filtered out as test or scaffolding files. They are excluded from the remediation scope, and listed rather than hidden. 1 of 22 stopped appearing once the in-scope fixes landed, almost always because they shared a root cause with something that was in scope. REACHABLE never asked the agent to touch them and they are not counted as fixed — the point of excluding them is that they did not need fixing. The other 21 are unchanged.

Additional scan context — 9 row(s)

Not remediation scope and not counted as noise. These rows were present in scanner context but were not in the product's actionable validation export for this source-remediation pass, so they are not counted as fixed or open remediation work.

Remediation Attempt

Started with 7 findings to fix. Iteration 2 fixed 0 issues; 7 issues left. 7 finding(s) still need attention.

7 security finding(s) still remain. Noise and context are listed separately on this page.

Pass-by-pass breakdown

Iteration 2: fixed 0 issues; 7 issues left

• None

How long it took

Wall clock, read from the scanner's own output and the remediation database timestamps.

← initial scan · this pipeline run