openai/codex-plugin-cc

This should be fixed now in #177

Great point -- from my own implementation as a skill they do overlap mechanically since both use threads under the hood. The difference is really about what I am trying to do with it.

With `rescue`, I'm handing off work -- "fix this test", "refactor this function". Codex has write access and the thread lives as long as the task needs it. Once it's done, I move on.

What I'm describing with `consult` is more like thinking out loud with Codex. I want to ask "how does the auth middleware work here?", get an answer, then follow up with "ok what would break if we replaced it with JWT?" -- and have that context carry across turns. No file modifications, just back-and-forth exploration.

From exploring the plugin I notice I could do this with `rescue --resume`, but it feels off a bit It's like I am giving Codex write access when all I want is a conversation. A dedicated command would make the intent clearer and keep things read-only by default.

That said, if the team feels `rescue --resume`...

@BBBOND
Thanks so much for sharing this fix — it worked perfectly! The approach of checking config.toml
for model or profile before falling back to codex login status makes a lot of sense, especially
for Azure OpenAI users whose auth isn't recognized by the native login flow.

Have you considered opening a PR to the codex repo? This feels like it
should be upstreamed rather than staying a local workaround — the logic is clean,
non-destructive, and addresses a real gap for anyone using custom model providers. Happy to
co-sign or comment on the PR if it helps!

I ran into the same issue where the Codex plugin keeps asking for login even though I already have ~/.codex/config.toml configured.
I temporarily fixed it by modifying the plugin source code via Claude Code. You can run the following command to have Claude automatically apply the fix for you:

```shell
claude -p "Modify the Codex plugin to check for existing config file authentication before running 'codex login status'.

File to modify: ~/.claude/plugins/marketplaces/openai-codex/plugins/codex/scripts/lib/codex.mjs

Changes needed:

1. Ensure these imports exist at the top of the file (add if missing):
import fs from \"node:fs\";
import os from \"node:os\";
import path from \"node:path\";

2. Replace the existing hasCodexConfigFile() function (or add if not exists) with this enhanced version named hasValidCodexConfig():

function hasValidCodexConfig() {
const homedir = os.homedir();
const configPath = path.join(homedir, \".codex\", \"config.toml\");

if (!f...

How would this be different than using `/codex:rescue`? It should by default suggest to use the same thread or you can use `/codex:rescue --resume [follow-up]` to be more explicit

Thank you! That's definitely odd since we moved from `readOnly` to `read-only` back in December. Will do some more digging with Codex

The binary from `which codex` also returns `codex-cli 0.117.0` (if it helps, it's located at `/Users/arvidkahl/Library/Application Support/Herd/config/nvm/versions/node/v21.7.3/bin/codex` as I run this through Herd and inside PHPStorm.

@arvidkahl inside bash can you run `which codex` and `codex --version`? There might be a version mismatch happening here.

Thanks for flagging. I'm looking into this!

I get similar issue with sandbox environment.

```
The Codex reviewer couldn't access the shell in its sandbox. The review output is above — it was unable to execute due to sandbox restrictions in this environment.
```