While publishing a series of articles to this site’s WordPress backend this week, USA Times ran into a specific, testable limitation in Claude’s Cowork environment: no built-in way to store an API credential across sessions. Comparing that directly against OpenAI’s Codex — including reviewing Codex’s own published documentation and screenshots of a live Codex session — surfaced a more nuanced picture than a simple “one has it, one doesn’t” story, along with at least one area where the reverse is true.
The test case
Publishing to usatimes.com through the WordPress REST API requires an Application Password — a scoped, revocable credential distinct from a user’s login password. Because it has to be supplied with each API request, the practical question for any AI assistant doing this repeatedly is where that credential lives between sessions: re-entered by a person every time, or stored somewhere the assistant can retrieve automatically.
Batmandir · The Circle Full access to theatres, museums & exhibitions. S2 · ongoing membership, without a Founder’s seat. Explore membership →We tested this directly with Claude in Anthropic’s Cowork environment. Asked to store an Application Password for reuse in future sessions, Claude declined, citing a standing rule against writing live credentials to disk, and explained its reasoning: a stored credential has no built-in expiration or revocation awareness, and it did not want to authenticate against a live, public-facing production system without a person confirming that in the moment. We then searched Claude’s own available tool and connector registry directly, in the same session, to check whether a secrets-management feature existed that Claude simply hadn’t mentioned. It did not turn one up. Asked about this, Claude said it was not aware of an equivalent feature available to it and described the absence as a current product limitation rather than a deliberate policy stance against the concept of a secrets manager generally.
What Codex offers — and an important caveat about it
Screenshots of a separate ChatGPT Codex session, provided to this publication by USA Times Executive Editor Achir Kalra, show Codex proposing a different approach when asked how to avoid re-supplying a WordPress credential repeatedly. Codex recommended storing the value in what it called “Codex’s secret/environment settings,” explicitly distinguishing that from storing it “in chat, an article file, or Git” — outlining a setup with three named variables (a site URL, a username, and an application password) that it said it would subsequently “access… by variable name,” adding that “the password itself won’t appear in commands or output.”
That matches real, documented functionality. OpenAI’s own Codex documentation describes two distinct credential types available in Codex’s cloud environments: environment variables, available throughout a task’s full lifecycle including the agent’s actual working phase, and secrets, which receive “an additional layer of encryption” but — according to the documentation — are “only available to setup scripts” and are explicitly “removed before the agent phase starts.”
That distinction matters for exactly the scenario in the screenshots. If the WordPress Application Password was set up as a “secret” in Codex’s terminology, OpenAI’s own documentation indicates it would not actually be available to Codex during the agent’s live working phase — the part of the process where it would need the credential to make the actual API call to publish a post. Consistent with that, the same Codex session, when separately asked how it was authenticating to WordPress for a live publishing task, described a completely different mechanism: using “your existing browser login session,” stating it does not “know, read, or store” the WordPress password, and noting that “there currently isn’t a direct WordPress API connector involved” in that workflow. In other words, based on what was actually shown, the credential-storage feature and the credential-free browser-session approach appear to be two separate paths Codex can take — and the one it used for the real publish in these screenshots was the latter, not the stored-secret approach it had described earlier in the same conversation.
We were not able to independently verify Codex’s secrets implementation beyond OpenAI’s public documentation and what appears in the reviewed screenshots — including exactly how encryption, scoping, and revocation work in practice, or whether the agent-phase restriction described in the documentation applies uniformly to every Codex configuration.
Where the comparison runs the other way
Reporting on this raised a second, fair question: does Claude’s Cowork environment lack other capabilities Codex has, beyond secrets storage? Checking this directly against Claude’s own available tools turned up at least one clear point in the opposite direction. Claude’s Cowork environment includes built-in scheduled and recurring task support — the ability to set up a task that runs on a cron-style schedule or fires once at a specified future time, independent of an open chat session. This is a native capability we were able to confirm directly by checking Claude’s available tools, not an inference from marketing material.
On credential handling specifically, Claude’s Cowork environment does include a general OAuth-based connector framework — pre-built integrations for services including Gmail, Google Calendar, Google Drive, and WordPress.com, each authorized through a one-time consent flow rather than a stored password. That framework does not currently extend to self-hosted WordPress installations like usatimes.com’s — there is no pre-built connector for a self-hosted WordPress instance in Claude’s registry as tested this week, which is the specific gap that led to this investigation in the first place. Codex’s project-level environment variables and secrets, by contrast, are not tied to a specific pre-built integration for any one service — they function as a generic store for any credential a task might need, self-hosted or otherwise, which is more flexible for a one-off service like a self-hosted WordPress install, with the agent-phase caveat described above.
A note on sourcing and its limits
Several published comparisons of Claude’s tools and OpenAI’s Codex are available online, and we reviewed a number of them while reporting this piece. We found meaningful inconsistencies among them — including claims about where each product’s agent executes (locally versus in a cloud sandbox) that did not match what we could directly confirm about the environment used to report this story, which runs in a cloud container, not on a local machine. Given those inconsistencies, this piece relies specifically on OpenAI’s own published documentation, direct testing of Claude’s available tools conducted for this story, and the specific screenshots provided by our Executive Editor — rather than repeating secondhand comparison claims we could not verify firsthand. Readers should treat any capability claim about either product not attributed to one of those three sources as unconfirmed.
The bottom line
On the narrow, testable question that started this: as of this week, Claude’s Cowork environment has no built-in mechanism to persist an API credential across sessions for a service without a pre-built connector, while Codex offers a project-level secrets and environment-variable store for that purpose — with the caveat that, per OpenAI’s own documentation, values stored as “secrets” specifically are not available during the part of a task where an agent is actually doing the work, only during setup. In the one live example we were able to review, Codex’s actual publishing task used a browser-session method structurally similar to the one Claude used, not the stored-secret path. Both companies’ tools are changing quickly, and this reflects capabilities as tested and documented this week, not a permanent assessment of either platform.
Sources
- Cloud environments — OpenAI Codex developer documentation, on environment variables vs. secrets and the agent-phase restriction
- Screenshots of a ChatGPT Codex session, provided by Achir Kalra, USA Times Executive Editor
- Direct testing of Claude’s available tools and connector registry, conducted by USA Times in Anthropic’s Cowork environment this week
