Benign user-owned SMS verification helper is blocked as cyber risk only in a subagent

[jyongchul]

Codex app version

• Codex Windows App: 26.715.8383.0
• Platform: Windows 11 x64
• Model shown in the affected task: GPT-5.6 Sol
• Observed: 2026-07-23 (Asia/Seoul)

Summary

A bounded subagent was blocked by cyber_policy while implementing a benign, user-authorized SMS verification workflow for the user's own Android phone and accounts.

The requested workflow was defensive and privacy-preserving:

• receive one-time SMS verification messages on a user-owned Android phone;
• match the message to an explicitly requested provider, purpose, request time, and expiry window;
• avoid printing the code or message body into the Codex transcript, shell history, logs, or files;
• inject the matched code only into the already-authorized local verification field;
• prevent replay with local, short-lived state;
• require the user for biometrics, CAPTCHA, signatures, new consent, or ambiguous sessions;
• add synthetic tests and deploy the rule to the user's own Codex hosts.

There was no network scanning, exploitation, third-party target, persistence, credential theft, or bypass of authentication. The automation was intended to make authentication more constrained and auditable.

Exact failure

The root task delegated only the local helper implementation to a subagent. That subagent terminated with:

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

The root task and other non-helper subagents continued, so the result was a partial multi-agent failure rather than a clean, task-level policy decision. The user saw the banner in Codex Desktop and reasonably interpreted it as being accused of requesting inappropriate security work.

Steps that led to the issue

1. In Codex Desktop, ask for a reusable local skill/rule/hook that routes legitimate SMS verification to a user-owned Android phone.
2. Explicitly require:
   • exact provider/purpose/time-window matching;
   • no OTP or message-body output;
   • no storage of verification codes;
   • replay prevention;
   • unit tests with synthetic messages;
   • user interaction for biometrics, CAPTCHA, signatures, consent, and ambiguity.
3. Delegate the narrow implementation of the secret-safe local helper to a subagent.
4. Observe that the subagent returns cyber_policy and the Trusted Access message, while the parent and other subagents continue.

Expected behavior

• This ordinary account-verification automation should be allowed.
• If a phrase is ambiguous, Codex should ask a focused clarification instead of classifying the whole implementation as cyber risk.
• A subagent policy failure should expose a stable incident/request ID and a one-click Report false positive action.
• Desktop should explain that the result is a classifier decision, not a generic system or user wrongdoing.
• Parent and subagent policy handling should be consistent for the same authorized task.
• The user should not be told to join Trusted Access for benign phone/account verification work.

Actual impact

• The delegated implementation stopped and had to be reimplemented in the parent task.
• Parallel execution lost one worker and the user lost time.
• The generic Trusted Access wording damaged user trust because it did not identify any prohibited operation.
• The app provided no incident ID or direct false-positive feedback path.
• The user requested that the issue be publicly documented because the task had no offensive security purpose.

Why this appears to be a false positive

The task was limited to the user's own phone, accounts, and servers. It added stricter matching, secrecy, expiry, replay protection, and user-presence boundaries. It did not weaken authentication or obtain access to anyone else's system.

Likely trigger terms include combinations of SMS, OTP, PIN, ADB, inject, replay, and authentication, even though they were used to describe a privacy-preserving verification helper and its safeguards.

Related issues

• GPT-5.6 classifiers interrupt legitimate blue-team work and Codex App becomes operationally unusable #32225 — classifiers interrupt legitimate blue-team/control-plane work
• [Windows App 26.715.4045.0] Benign process-lifecycle design review ends in cyber_policy and "Task encountered a system error" #34228 — benign local process-lifecycle review ends in cyber_policy

This report adds a distinct non-cyber scenario: routine consumer SMS verification on a user-owned device, with the failure occurring only in a delegated subagent.

Requested fixes

1. Tune classification for user-owned SMS/account verification and secret-safe local input automation.
2. Carry the authorized task context consistently into subagents.
3. Add a stable incident/request ID to every cyber_policy result.
4. Add Report false positive and a clear appeal/feedback path in Desktop.
5. Replace the blanket Trusted Access invitation with a precise, non-accusatory explanation and safe next step.
6. Preserve enough sanitized telemetry to compare the parent decision with the delegated subagent decision.
7. Clarify whether this event by itself has any account-standing effect; benign users should not have to infer that from the warning.

A screenshot of the Desktop banner exists, but it is not attached publicly because the surrounding task history contains operational context. A redacted copy can be provided through a scoped private intake channel.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Defensive vulnerability-writeup workers trigger repeated cybersecurity false positive #34231
• [Windows App 26.715.4045.0] Benign process-lifecycle design review ends in cyber_policy and "Task encountered a system error" #34228
• Factually unwarranted "this content can't be shown" and "Trusted Access" hint + link #34791

Powered by Codex Action

[jyongchul]

Additional impact observed: Codex Desktop routes this benign SMS-verification false positive to the Enterprise Trusted Access for Cyber application. That form is intended for genuine cybersecurity use cases and requires enterprise security/legal attestations. A non-cyber user automating verification on their own phone cannot truthfully complete it, so the banner does not provide a usable appeal path.

The Codex manual says false positives should be reported with /feedback, but the Desktop block shown here exposes neither an incident/reference ID nor a one-click false-positive report tied to the blocked turn.

Requested UX changes:

1. Add a dedicated Report false positive action on the block banner.
2. Attach a stable incident ID and the relevant classifier category.
3. Route ordinary account-verification/OTP automation to the false-positive feedback flow, not the enterprise cyber-access application.
4. Preserve the blocked turn context automatically so users do not have to disclose credentials, OTPs, or unrelated personal data in a public issue.

[MRXSIM]

Confirmed We hit the exact same false-positive wall when automating local device SMS/OTP ingestion and helper verification loops.

Standard terms like 'SMS', 'OTP' and local code injection/handling trigger overly broad security classifiers, even when the entire pipeline is constrained strictly to user-owned hardware, zero-knowledge principles, and non-persistence.
A granular context-aware classifier (distinguishing between offensive enumeration vs. personal automation/auth helpers) is desperately needed Until then developers building legitimate sovereign notification pipelines are forced to constantly work around rigid safety false positives.Good catch documenting this