Repository navigation
Safeguard refusals fail a Security run, and each security session's Model is logged #547
Description
Activity
Closed by #577, merged into issue-427 by a thirdshift Merge run.
This was generated by AI during triage.
Filed #603 as a
bug/ready-for-agentfollow-up for stage reporting. A real Security run completed its audit and recorded its findings privately, then its first reproduction received Codex's cybersecurity safeguard refusal. The notification described both the overall result and Audit asaudit failed.The refusal handling specified here worked as intended: the Security run failed, kept its private records, stopped before the next reproduction, and dispatched no fix. #603 asks outcome accounting and Run notifications to preserve the completed audit's status and identify the failed reproduction separately. This does not reopen or change this issue's refusal-handling contract.
Parent
#427
What to build
Refusals. A security session can be refused by a model's safeguard: Claude Code's
[cyber]refusal, or Codex's cybersecurityturn.failed. The Security audit, reproduction and fix-publishing sessions are security sessions. A refused session fails its Security run, with a cause that names the refusal. So does one that ends without its final line.Models. A progress line names the Model each security session actually answered on, so that a switch such as Opus 5.5 to Opus 4.8 shows in the Command log. For Claude Code, that's the Model its stream reports; for Codex, the one requested.
Acceptance criteria
[cyber]refusal fails the Security run, with that cause.turn.failedfails the Security run, with that cause.