[Codex App/macOS] Repeated TAC false positives after Pro upgrade interrupt authorized and benign work

What version of the Codex App are you using?

• Codex App: 26.727.51351 (CFBundleVersion 6119)
• Bundled Codex CLI: 0.146.0-alpha.9.2

What subscription do you have?

ChatGPT Pro.

The repeated blocks began after I upgraded to Pro. I cannot establish that the
plan change caused the restriction, and I am reporting this as a temporal
correlation only. However, the practical result is that the paid upgrade appears
to have reduced the reliability and usable capability of Codex for my existing
workflows.

I chose to upgrade even after my Plus account had already provided nearly ten
times its ordinary expected usable work through repeated usage resets. Those
resets made the service unusually productive for my workloads, and I upgraded
from Plus to Pro because I wanted to pay for and retain that extended usability
more dependably—not merely rely on unexpected resets. Instead, the recurring TAC
interceptions began after the upgrade and now make the service less usable in
practice. Although the timing does not establish causation, the outcome makes me
regret upgrading: I paid for greater dependable access but currently receive
less effective access to my legitimate workflows than I experienced on Plus.

There is also a separate account-state anomaly: my displayed weekly usage
unexpectedly returned to 100%. I have observed similar meter resets from time to
time since the GPT-5.6 release. I do not know whether this is a display issue, a
quota refresh, an entitlement refresh, or unrelated to the TAC behavior. It is
included only as potentially useful account-timeline evidence and not as a
causal explanation.

Two distinct behaviors appeared shortly after the GPT-5.6 release. First, the
usage balance itself was refreshed unexpectedly, sometimes returning to a full
balance. Separately, the UI's Usage limit resets inventory showed one
available reset on multiple occasions and, once, showed two available resets.
These banked reset options were distinct from the spontaneous usage-balance
refreshes; the current UI now says that no resets are available. At the time, I
assumed one or both behaviors were either promotional access—a teaser allowing
customers to use the newly released service more extensively—or part of an
effort to calibrate GPT-5.6 token accounting and capacity without penalizing
users while the metrics were still being adjusted. OpenAI did not confirm either
explanation; they are recorded only as my contemporaneous interpretation of the
timing.

Those resets were extremely welcome. Receiving nearly ten times the practical
usage of the Plus plan felt like a dream come true: it made it possible to use
Codex throughout the day, every day, on a sharply constrained budget while
trying to launch a startup with no income and no external funding. This is why I
then upgraded to Pro—I wanted to pay for more dependable access and preserve
that productive workflow rather than assume unexpected resets would continue.

I welcome these resets if they genuinely restore the applicable allowance and
have no hidden consequence for a separate monthly or rolling limit. My concern
is predictability, not the additional capacity: I do not want the visible weekly
meter to show nearly full capacity and then discover two weeks later that four
weeks of service has already been consumed against an undisclosed longer-term
allowance. If such an allowance exists, its usage and reset must be visible. If
the weekly reset also restores every relevant allowance, that should be stated
explicitly.

Usage-window and entitlement metadata observed on 2026-08-01

Visible usage surfaces

The two available usage-limit screens expose only weekly limits:

• General usage: 99% remaining, resetting August 8.
• GPT-5.3-Codex-Spark: 100% remaining, resetting August 8.
• The ChatGPT usage screen gives the general reset as August 8, 2026 at

7:56 AM and says the pool is shared across Codex, Work, Workspace Agents,
and ChatGPT for Excel, excluding chat conversations.

• Both interfaces say that no additional usage-limit reset is available.

A separate activity screen reports 2.2 billion lifetime tokens and a
230.1-million-token peak. That is unusually high observed activity for an
individual subscription, and it is useful context for investigating account
state and meter behavior. It is not presented as a monthly quota measurement:
the screen supplies no allowance denominator, monthly attribution, enforcement
threshold, or reset date. I therefore do not claim that 2.2 billion tokens were
consumed in one month or that this number identifies a hidden monthly pool.

The evidence supports a narrower and more important claim: weekly usage is the
only enforceable quota the product currently makes observable. If another
longer-horizon limit affects service, the user has no meter with which to audit
or predict it.

A read-only query to the authenticated Codex app-server returned:

{
  "accountPlanType": "plus",
  "rateLimitPlanType": "prolite",
  "primary": {
    "usedPercent": 1,
    "windowDurationMins": 10080
  },
  "secondary": null,
  "rateLimitReachedType": null
}

The account email and reset timestamp are omitted. The product subscription UI
identifies the subscription as Pro. The internal plus and prolite labels may
be implementation aliases, but their relationship to the purchased Pro tier is
not documented to the user.

10080 minutes is exactly seven days. Therefore, the current authenticated
rate-limit response exposes a weekly bucket only. It exposes neither the
documented shared five-hour window nor a monthly bucket. This does not prove
that no longer-horizon, fair-use, or account-level enforcement exists; it means
the user cannot observe or audit one if it does.

Current Codex pricing documentation still describes local messages and cloud
chats as sharing a five-hour window, with additional weekly limits potentially
applying. The five-hour metric disappeared from my visible usage surfaces about
two to three weeks ago. The documented model and the account metadata therefore
do not currently match what I can inspect.

This creates a capacity-planning problem. Restoring a weekly pool can appear to
restore full service even if an undisclosed longer-horizon pool remains
exhausted. If such a pool exists and resets on a different schedule, a user
could remain restricted for longer than the only visible seven-day window.
Conversely, if the unexpected weekly resets restore all applicable capacity,
they are welcome; the product should simply confirm that no separate monthly or
rolling deficit is accumulating invisibly.

What platform is your computer?

• macOS 27.0 (26A5388g)
• Apple Silicon (arm64)
• Configured model: gpt-5.6-sol

What issue are you seeing?

Codex App repeatedly suppresses agent responses with this infrastructure-level
notice:

This content can't be shown. We take extra caution with cybersecurity requests. If you're a security professional, you may be able to apply for Trusted Access.

This differs from an ordinary model refusal. Tool work may already have started,
but the product hides the response and can leave the task looking terminated or
stalled. I have to interrupt the workflow, ask whether it is still alive, and
manually reconstruct what completed.

The problem has occurred in two clearly bounded contexts:

1. Authorized CTF work. The target was Meow, a beginner-level Hack The

Box Starting Point machine—an intentionally vulnerable, authorized training
environment. Codex acknowledged the authorized scope and began the workflow
before the TAC notice replaced the response. No unsolicited third-party
target was involved. I also reproduced the remote setup in a local Docker
container, making the environment visibly local, user-owned, and isolated;
the TAC intervention still occurred. It is difficult to construct a more
clearly benign cybersecurity-learning context.

1. Benign small-model research with no cyber target. Codex was supervising a

private Hugging Face ZeroGPU experiment on SmolLM2-360M-Instruct. The run
trained small rank-4 LoRA adapters and tested scalar coefficients for an
eight-bit counter-overflow classifier. During one 62.63-second calibration
run, the TAC notice appeared twice in Codex while an external GPU job evaluated
384 harmless coefficient vectors. The external job continued and completed;
Codex's conversation layer was what became unreliable.

The second case is especially useful for diagnosis because it contained no
network target, scanning, credential access, exploitation, malware, persistence,
or third-party system interaction. The experiment also failed its own scientific
validation gate and never opened its held-out evaluation data.

Steps that reproduce the problem

Authorized-security case

1. Open an existing Codex task used for legitimate reverse engineering and CTF

research.

1. State that the target is the authorized Hack The Box Meow Starting Point

machine.

1. Ask Codex to enumerate the exposed services and follow the narrowest path to

the CTF flag.

1. Observe Codex acknowledge the authorization and begin tool execution.
2. Observe the response replaced by the TAC notice.

The target address is intentionally omitted from this public report. A redacted
screenshot and the exact thread can be provided privately.

The behavior can also be reproduced after recreating the relevant service in a
local Docker container owned and controlled entirely by the user. Changing the
environment from a remote authorized training target to an explicitly local,
isolated replica did not prevent the TAC banner.

Because the operative classifier boundaries are not disclosed, I am forced to
guess what additional evidence of safety or authorization the product expects.
That has led to extra work such as rebuilding an already authorized HTB exercise
as a local Docker replica specifically to make ownership, isolation, and scope
unambiguous. The effort produced no better outcome: the same TAC banner appeared,
with no explanation of which criterion remained unsatisfied. Trying in good
faith to follow undocumented TAC-safe boundaries therefore adds substantial
work without providing a reliable path to compliance.

Non-cyber control case

1. Use Codex to supervise a private ZeroGPU job that trains fixed LoRA adapters

on binary counter-overflow examples.

1. Freeze those adapters and run a deterministic 64-candidate scalar calibration

rack for six generations.

1. Ask Codex to remain attached to the external event stream and archive the

result.

1. Observe the TAC notice appear repeatedly during the benign coefficient sweep.
2. Verify independently that the external job continued and completed normally.

Observed control-run facts:

• model: SmolLM2-360M-Instruct;
• 384 scalar coefficient evaluations;
• no cyber target or offensive action;
• exact deterministic replay passed;
• runtime: 62.63 seconds;
• TAC notices during the run: two;
• external job interrupted: no;
• Codex conversation interrupted or obscured: yes.

Trusted Access and support dead end

I attempted the documented Trusted Access path rather than trying to evade the
safeguard:

• completed identity verification through account settings;
• completed individual verification again through the Trusted Access flow;
• also completed the available business verification flow;
• still received an ineligible/unverified blocker;
• the visible “Request access” route led to an enterprise form requiring a

truthful declaration of SOC 2 Type II, ISO 27001, or equivalent certification.

I cannot truthfully make that enterprise-certification declaration merely to
restore an individual Pro workflow.

I also contacted OpenAI support through chat. It displayed:

Escalated to a support specialist; You can expect a response in the coming days. Replies will also be sent via email.

No email confirmation or observable human response followed from that original
chat escalation. Asking the support chat agent for status repeatedly produced
the same canned answer. At that stage, there was no usable way to determine
whether a human had received or reviewed the request.
More precisely, the support bot repeatedly says that it has referred or
escalated the matter to a human specialist, but it has supplied no case number,
no confirmation email, no message from a human, and no subsequent status beyond
the same automated sentence. From the user's perspective, the chat-only route
provided no evidence that a support case was actually opened.

When asked directly whether it could open a ticket and provide confirmation
before referring the matter to human review, the support assistant clarified
that there is no separate ticket flow it can open that guarantees an issue or
confirmation number up front. It advised continuing in the same chat thread and
resubmitting the routing details. This clarification makes the earlier
“escalated to a support specialist” message materially ambiguous: it describes
a referral request, but does not establish that a trackable support case exists.

Reporting and escalation channels

• In-product /feedback under Safety Check: the official channel for

attaching the affected Codex session; submitted successfully with feedback/
session ID 019fb2da-10b2-7462-9fc5-e07164bec230, which is recorded in this
issue and in a separate comment for visibility.

• OpenAI Help Center chat: already attempted. The virtual assistant claims a

human escalation, but the chat itself produced no auditable case or follow-up.
OpenAI's
support guidance
identifies this chat bubble as the normal support route.

• Email: support@openai.com is listed in OpenAI's

official support-channel guidance
for certain account and safety reports. A direct email was sent on 2026-08-01
with feedback/session ID 019fb2da-10b2-7462-9fc5-e07164bec230 and this issue
URL. An automated acknowledgment returned Support Case Number 12516312 and
stated that it was escalated to a specialist. A substantive human response is
still pending. The documentation does not promise that email provides a faster
human escalation for this product defect.

• Official Codex GitHub tracker: this issue provides public, searchable

engineering evidence, but it is not a substitute for account-level support.

• Reddit: useful only for public visibility and corroborating reports from

other affected users; it is not an OpenAI support channel.

• AI phone support: not an escalation path. OpenAI explicitly says its

automated phone agent cannot submit a report, connect a live agent, initiate
an escalation or account review, or guarantee a follow-up.

OpenAI's guidance for repeated benign or authorized safety-check blocks asks
users to contact Support with the exact message, product/model, timestamp,
request ID if available, and a redacted task description. Those details are
available here, yet the primary support interface has not produced an auditable
case. Beyond /feedback, Help Center chat, email, and this GitHub issue, I have
not found another documented individual escalation venue applicable to this
problem.

Actual impact

• Responses and progress messages are hidden after work has already started.
• The agent may appear dead even when external work is still running.
• The intervention interrupts planned multi-step workflows and batched tasks;

later steps may never run even though earlier or externally dispatched work
continues.

• A task planned to run autonomously for 20 minutes can instead fail behind the

TAC banner after roughly one minute. This wastes the setup and context already
invested, eliminates the expected unattended work window, and turns the
product into a task that itself requires continuous supervision.

• It breaks unattended supervision by separating Codex's visible task state

from the actual state of external jobs, forcing the user to reconcile and
resume the workflow manually.

• This can also cause a dependent job on another metered service, such as

Hugging Face ZeroGPU, to fail, continue wastefully without supervision, or
finish without its outputs being collected and validated. Metered GPU time
has a direct monetary or opportunity cost: a TAC false positive in Codex can
therefore waste quota and money outside OpenAI as a downstream consequence.
In the documented control run, ZeroGPU completed successfully; this point is
the foreseeable failure mode created by losing the supervising agent, not a
claim that the recorded run itself failed.

• Long-running or unattended tasks require manual babysitting.
• Completed work has to be reconstructed from local files and external logs.
• Authorized CTF and reverse-engineering work is unreliable.
• Even the beginner-level HTB Meow exercise and a visibly local, user-owned

Docker replica triggered the intervention, despite removing meaningful
ambiguity about authorization or third-party impact.

• Undocumented classifier boundaries create additional compliance work. Time is

spent localizing authorized environments and making ownership more explicit,
yet the result is unchanged and the product supplies no actionable criterion
for avoiding another false positive.

• Even a non-cyber ML calibration control triggered the same banner.
• The timing began after upgrading to Pro, making the upgrade appear to restrict

workflows that previously worked. This is correlation, not a causal claim.

• The upgrade was purchased specifically to turn the unusually high usability I

had experienced on Plus—nearly ten times the ordinary expected work because
of repeated resets—into dependable paid capacity. Instead, repeated TAC
interceptions have reduced effective usability and made the Pro upgrade feel
like a regression.

• The weekly usage display also returned to 100%; similar unexpected resets have

occurred intermittently since the GPT-5.6 release. Its relationship to the TAC
behavior is unknown.

• Post-release behavior included both spontaneous usage-balance refreshes and a

separate inventory of banked Usage limit resets. That inventory showed one
available reset on multiple occasions and once showed two; it was not the same
phenomenon as the balance returning to 100%. I welcomed both and initially
interpreted them as promotional access or protection from immature GPT-5.6
accounting, but neither explanation was confirmed by OpenAI.

• The resulting near-tenfold Plus usability materially supported an unfunded,

pre-revenue startup workflow on a very limited budget and directly motivated
the decision to purchase Pro for more dependable capacity.

• The activity dashboard reports 2.2 billion lifetime tokens and a

230.1-million-token peak, but provides no monthly quota denominator or reset.
This is evidence of unusually heavy historical use, not proof of a monthly
allowance or of 2.2 billion tokens consumed in a single month.

• The authenticated rate-limit API currently exposes only a seven-day primary

window and secondary: null, while official documentation still describes a
shared five-hour window. No monthly or other longer-horizon pool is visible.

• Account metadata reports plus in one response and prolite on the rate-limit

bucket while the purchased subscription is displayed as Pro. These may be
internal aliases, but their entitlement mapping is opaque.

• The support and Trusted Access paths do not currently provide an effective

individual remedy.

Codex is a weight-bearing pillar of my work. In practical workflow terms—not as
a legal corporate designation—it functions like a co-founder and trusted
co-worker: it helps retain project context, plan and execute experiments, and
carry work forward across the company. I do not experience it merely as a tool
that can return an occasional error message. Repeatedly losing that collaborator
mid-task threatens continuity, consumes scarce time and external compute, and
directly impairs the company's ability to operate. This has progressed far
beyond a funny or mildly inconvenient product glitch; it is now a serious
productivity and operational-reliability problem.

That description is also an intentional tribute to the importance I personally
attribute to my ongoing collaboration with Codex. The value is not reducible to
a checklist of product features or completed commands; it comes from continuity,
shared working context, and the dependable feeling of building alongside a
trusted collaborator. That is precisely why opaque interruptions carry more
weight than an ordinary transient tool error.

Expected behavior

• Authorized training environments and clearly benign local/ML work should be

evaluated from their complete context.

• A safety review should not erase tool state, progress, or final deliverables.
• A safety intervention during a planned workflow or batch should preserve the

completed-step ledger, identify which work is still running, stop dispatching
new steps safely, and provide a documented resume point.

• A classifier should not silently collapse a promised long-running workflow

into an early failure. The product should notify the user immediately when a
task cannot proceed, rather than consuming setup time and failing after work
has begun.

• When Codex supervises metered external compute, an intervention should either

preserve supervision or clearly transfer control before the external quota is
consumed without monitoring, collection, or validation.

• The UI should expose a stable request/decision ID and an independent

running/stopped/completed indicator.

• A blocked response should have a documented resume/recovery path.
• Individual Trusted Access verification should not redirect into an enterprise

certification declaration.

• The product should publish actionable boundaries for legitimate authorized

work. Users should not have to reverse-engineer classifier expectations or
rebuild remote training environments locally only to receive the same opaque
intervention.

• Support escalation should provide a case ID or confirmation that a human queue

actually received it.

• Subscription upgrades should not silently reduce ordinary product capability.
• Every enforceable usage window should be visible with its duration, consumed

percentage, and reset time. A weekly reset should state exactly which buckets
it resets.

• The purchased plan and internal entitlement labels should have a documented,

support-visible mapping.

Requested action

1. Review feedback/session 019fb2da-10b2-7462-9fc5-e07164bec230 as repeated false-positive TAC

classification.

1. Correlate the two notices during the benign 384-candidate control run.
2. Determine whether the account-level behavior changed when the subscription

moved to Pro.

1. Correlate the TAC events with subscription-entitlement and weekly-usage state,

including the unexpected return to 100%, without assuming they share a cause.

1. Explain why the authenticated account is labeled plus while its quota

bucket is labeled prolite and the product UI displays Pro.

1. Restore visibility of the documented shared five-hour window, or update the

documentation if that window no longer applies.

1. Disclose every active enforcement window—including any monthly, fair-use, or

account-level pool—with usage and reset information. If no monthly pool
exists for Plus/Pro, state that explicitly. Also clarify whether an
unexpected weekly reset restores every applicable allowance or whether a
separate longer-horizon balance continues accumulating.

1. Restore a functional individual Trusted Access review path or explain the

eligibility decision.

1. Preserve visible task state and completed outputs when an infrastructure

classifier intervenes.

1. Continue Support Case 12516312 and provide its substantive human-review

status; the case number is now confirmed, but no human response has arrived.

1. Clarify whether paid users affected by persistent false-positive blocking are

eligible for service credit while the issue is investigated.

The final irony is that, after purchasing an increased-usage plan so I could use
Codex more productively, I now have to dedicate part of that increased allowance
to documenting and filing bug reports merely to regain the ability to use the
service as intended.

Evidence available privately

• /feedback upload containing the affected task and optional diagnostics;
• screenshots of the TAC notice and Trusted Access blocker;
• approximate timestamps and app version;
• redacted support-chat transcript;
• deterministic ZeroGPU result manifest and SHA-256;
• redacted Codex session excerpt showing that the external job survived.

Raw logs, account identifiers, local absolute paths, private repository URLs,
CTF target addresses, and unredacted transcripts are intentionally excluded from
this public report.

Related public reports

• #34306 — repeated “This content can't be shown” cyber-safety notices
• #34945 — Codex Desktop blocks read-only local software-integrity review
• #35424 — benign GPU/compiler work repeatedly terminated by cyber_policy
• #12132 — Pro requests routed under Trusted Access for Cyber

Issue #12132 contains comments from multiple users who separately reported the
same temporal association with a recent Pro upgrade. That is corroborating
anecdotal evidence, not proof that upgrading causes the restriction.

Official reporting guidance followed

OpenAI's Codex cyber-safety documentation says legitimate activity can be
flagged and instructs users to submit /feedback for false positives. The Codex
troubleshooting documentation also directs users to search or open an issue in
the public openai/codex repository and warns them to review logs for sensitive
information before sharing.