This commit is contained in:
DevNinja 2026-07-16 09:12:51 +00:00 committed by GitHub
commit 55cf9028ef
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 14 additions and 0 deletions

View File

@ -1571,6 +1571,13 @@ If token count is not available, display: `Tokens: unknown`
- **Binary not found:** Detected in Step 0. Stop with install instructions.
- **Auth error:** Codex prints an auth error to stderr. Surface the error:
"Codex authentication failed. Run `codex login` in your terminal to authenticate via ChatGPT."
- **Auth error — `refresh_token_reused` specifically (Hermes-aware recovery):**
When stderr contains `refresh_token_reused`, do **not** go straight to `codex login`. Hermes' `openai-codex` provider can still be serving valid tokens while the standalone `~/.codex/auth.json` credential store has gone stale (split-brain auth). Sending the user to `codex login` in that state wipes a working session that downstream skills relied on.
Diagnose, then repair, in this order:
1. **Smoke-test the Hermes provider first** (if Hermes is installed). Run any trivial request through Hermes' `openai-codex` provider using whatever invocation the local Hermes install documents (`hermes --help` lists its commands; a profile routed to `openai-codex` also works). If the call succeeds, the user's OpenAI session is still good; the failure is local to standalone `codex exec`'s credential store.
2. **If Hermes works:** repair `~/.codex/auth.json` from the Hermes-side tokens instead of forcing a re-login. Hermes stores its provider credentials in its own state directory — find where the `openai-codex` provider keeps its OAuth tokens (check the Hermes install's docs or config; there is no standard gstack helper for this), copy the refreshed `access_token` / `refresh_token` values into `~/.codex/auth.json`, then `chmod 600 ~/.codex/auth.json` and rerun the original `codex exec` to verify.
3. **If Hermes is not installed or the Hermes provider also fails:** that confirms the OpenAI session itself is gone; `codex login` is the right next step. Run it, then re-invoke the skill.
Tell the user which branch you're on before suggesting any action — "Hermes provider still works, repairing `~/.codex/auth.json` from Hermes tokens" vs. "Hermes provider is also down, running `codex login`" — so they know whether they're about to lose a working Hermes session or not.
- **Timeout (Bash outer gate):** If the Bash call times out (5 min for Review/Challenge, 10 min for Consult), tell the user:
"Codex timed out. The prompt may be too large or the API may be slow. Try again or use a smaller scope."
- **Timeout (inner `timeout` wrapper, exit 124):** If the shell `timeout 600` wrapper fires first, the skill's hang-detection block auto-logs a telemetry event + operational learning and prints: "Codex stalled past 10 minutes. Common causes: model API stall, long prompt, network issue. Try re-running. If persistent, split the prompt or check `~/.codex/logs/`." No extra action needed.

View File

@ -640,6 +640,13 @@ If token count is not available, display: `Tokens: unknown`
- **Binary not found:** Detected in Step 0. Stop with install instructions.
- **Auth error:** Codex prints an auth error to stderr. Surface the error:
"Codex authentication failed. Run `codex login` in your terminal to authenticate via ChatGPT."
- **Auth error — `refresh_token_reused` specifically (Hermes-aware recovery):**
When stderr contains `refresh_token_reused`, do **not** go straight to `codex login`. Hermes' `openai-codex` provider can still be serving valid tokens while the standalone `~/.codex/auth.json` credential store has gone stale (split-brain auth). Sending the user to `codex login` in that state wipes a working session that downstream skills relied on.
Diagnose, then repair, in this order:
1. **Smoke-test the Hermes provider first** (if Hermes is installed). Run any trivial request through Hermes' `openai-codex` provider using whatever invocation the local Hermes install documents (`hermes --help` lists its commands; a profile routed to `openai-codex` also works). If the call succeeds, the user's OpenAI session is still good; the failure is local to standalone `codex exec`'s credential store.
2. **If Hermes works:** repair `~/.codex/auth.json` from the Hermes-side tokens instead of forcing a re-login. Hermes stores its provider credentials in its own state directory — find where the `openai-codex` provider keeps its OAuth tokens (check the Hermes install's docs or config; there is no standard gstack helper for this), copy the refreshed `access_token` / `refresh_token` values into `~/.codex/auth.json`, then `chmod 600 ~/.codex/auth.json` and rerun the original `codex exec` to verify.
3. **If Hermes is not installed or the Hermes provider also fails:** that confirms the OpenAI session itself is gone; `codex login` is the right next step. Run it, then re-invoke the skill.
Tell the user which branch you're on before suggesting any action — "Hermes provider still works, repairing `~/.codex/auth.json` from Hermes tokens" vs. "Hermes provider is also down, running `codex login`" — so they know whether they're about to lose a working Hermes session or not.
- **Timeout (Bash outer gate):** If the Bash call times out (5 min for Review/Challenge, 10 min for Consult), tell the user:
"Codex timed out. The prompt may be too large or the API may be slow. Try again or use a smaller scope."
- **Timeout (inner `timeout` wrapper, exit 124):** If the shell `timeout 600` wrapper fires first, the skill's hang-detection block auto-logs a telemetry event + operational learning and prints: "Codex stalled past 10 minutes. Common causes: model API stall, long prompt, network issue. Try re-running. If persistent, split the prompt or check `~/.codex/logs/`." No extra action needed.