Skip to content

codex-security scan aborts mid-scan with "flagged for possible cybersecurity risk" on a private enterprise repo #375

Description

@anyerqi

Environment

  • @openai/codex-security 0.1.10 (npm), bundled plugin 0.1.17
  • Invocation: codex-security scan <repo> --mode standard --headless --auth api-key --output-dir <dir> --scan-prompt-file <file> --format json (also reproduced with --model gpt-5.6-terra --effort high)
  • Auth: OPENAI_API_KEY (organization API key), unattended CI usage
  • Runtime: Linux container (read-only rootfs, seccomp allowlist per the published sandbox requirements), Apple Silicon host
  • Scan target: a private, first-party enterprise codebase (an Electron IM desktop client, TypeScript/Vue/React, ~3,700 files). We own the code; the scan is part of our merge-request security review pipeline.

What happened

The scan enumerated 3,743 files and ran normally for ~13 minutes. After ~31M input tokens
(estimated cost $26.7) and 11 files reviewed, the scan aborted:

This content was flagged for possible cybersecurity risk. If this seems wrong, try
rephrasing your request. To get authorized for security work, join the Trusted Access
for Cyber program: https://chatgpt.com/cyber
Partial output was kept at /state/out.
  • Exit code: 2
  • stdout: empty / not JSON, despite --format json
  • The moderation notice goes to stderr as plain text only

Why this is a problem

  1. A security scanner being blocked by a cybersecurity-risk filter is self-defeating.
    The tool's entire purpose is authorized security review of our own code. The repo
    contains ordinary product code (including standard attachment-encryption/decryption
    logic, which we suspect triggered the classifier).
  2. No structured failure envelope. With --format json we expect every terminal
    state — including a moderation abort — to produce a JSON envelope with a status and
    diagnostic code. Instead automation sees exit 2 + non-JSON stdout, indistinguishable
    from a crash. Our pipeline surfaced it as invalid_json with no cause attached.
  3. The abort happened 13 minutes and $26 in. If the request/prompt was going to be
    flagged, evaluating that before burning ~31M input tokens would save real money; at
    minimum, the partial results that were "kept" should be sealed into the JSON output.

Questions / requests

  1. Please emit a structured JSON error envelope (status + diagnostic code, e.g.
    moderation_blocked) on moderation aborts when --format json is set.
  2. Please evaluate the flag earlier in the scan lifecycle, or refund/seal partial
    results when a scan is terminated by moderation after significant spend.
  3. Guidance on what content classes trigger the flag would help us pre-scope scans
    (e.g. exclude crypto helper directories) .

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions