Two Codex signals landed within a few hours of each other today. One affects how people read their usage meter. The other makes a security workflow available outside the hosted product.
Both are useful. Neither should be turned into a bigger claim than the evidence supports.
1. A usage reset is an operational signal, not a contract
Tibo Sottiaux said that usage limits were reset for ChatGPT Work and Codex users after a GPT-5.6 Sol issue was addressed. His update also said subscription limits were not reduced, that typical Sol usage should last about 18% longer after the fix, and that the temporarily paused five-hour usage window would resume the following day.
That explains a sudden change in the meter. It does not, by itself, prove that every account now has the same long-term burn rate.
If usage matters to your workflow, collect a few comparable runs:
- starting and ending percentage
- model and reasoning effort
- task type and duration
- time within the five-hour window
- whether the run completed or was interrupted
Three comparable sessions are more useful than one screenshot. Treat UI meters as operational telemetry, not a permanent product guarantee.
Source: Tibo's update on X
2. Codex Security now has a public CLI and TypeScript SDK
OpenAI's new @openai/codex-security repository describes a CLI and TypeScript SDK for finding, validating, and fixing vulnerabilities, reviewing changes, tracking findings, and running checks in CI.
The quick start is short:
npm install @openai/codex-security
npx codex-security login
npx codex-security scan .
The important constraints are in the same README: Node.js 22+, Python 3.10+, and access to Codex Security are required. A public package does not mean every account has access, and an AI-generated fix is not automatically safe to merge.
A useful evaluation should pin a repository commit and answer four questions:
- Can the scan reproduce a known vulnerability?
- Can a human reviewer verify the evidence?
- Does the proposed patch survive tests and a second review?
- How much time and quota does the complete run consume?
Finding count is a weak headline metric. Reproducible evidence, patch quality, and operating cost are the metrics that decide whether this belongs in every commit, a release checkpoint, or only a deeper audit.
Sources: OpenAI's Codex Security repository and the official CLI documentation
The practical takeaway
The common thread is verification. For usage, compare repeatable runs instead of inferring policy from one meter change. For security, compare reproducible findings and tested fixes instead of trusting a severity label.
That is less exciting than declaring the limits “fixed” or security “solved.” It is also how these tools become dependable parts of a real workflow.
AI-assisted disclosure: I used AI to help organize and edit this roundup. I checked every factual claim against the primary sources above and take responsibility for the final text.
Top comments (0)