You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex fails to report failure if unauthorised #668
https://github.com/webgrip/n8n-application/actions/runs/17798306042/job/50591153315#step:11:163 I'm not seeing anything actionable on my end. Another thing to maybe think about: My org has a secret called OPENAI_API_KEY_CI. If somehow the name of the secret that's used to send to OAI was configurable, that would solve a lot of useless work / secret duplication. Or maybe let a manually defined env variable overwrite the secret env var used in the step if it's set?
It's still strange, because I'm 100% sure that the key I'm using is valid. So I'm just unsure on general on what's going on in my case.
- name: Run Codexrun: | set -o pipefail INSTRUCTION=$(cat /tmp/aw-prompts/prompt.txt) export CODEX_HOME=/tmp/mcp-config # Create log directory outside git repo mkdir -p /tmp/aw-logs # where is Codex which codex # Check Codex version codex --version # Authenticate with Codex codex login --api-key "${{ secrets.OPENAI_API_KEY }}" # Run codex with log capture - pipefail ensures codex exit code is preserved codex exec -c model=gpt-5-preview --search --full-auto "$INSTRUCTION" 2>&1 | tee /tmp/agentic-triage.logenv:
GITHUB_AW_PROMPT: /tmp/aw-prompts/prompt.txtGITHUB_AW_SAFE_OUTPUTS: ${{ env.GITHUB_AW_SAFE_OUTPUTS }}GITHUB_STEP_SUMMARY: ${{ env.GITHUB_STEP_SUMMARY }}OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY_CI }}
is what I get when I compile after running
gh extension upgrade --all
[aw]: upgraded from v0.6.2 to v0.7.0
codex login uses the secret. If it uses the environment variable instead, it's perfect. Right now it'll always use the secret, even though the point of the environment variable is to be able to serve exactly my use case ;)
Actually strange, I see codex 0.36.0 supporting this
dsyme@DSYME-LAPDOG:~/gh-aw$ codex --help | grep search
--search
Enable web search (off by default). When enabled, the native Responses `web_search` tool is available to the
dsyme@DSYME-LAPDOG:~/gh-aw$ codex --version
codex-cli 0.36.0
Activity
github-actions commentedon Sep 10, 2025
Created related issue: #669
dsyme commentedon Sep 10, 2025
Closed by e2e test cleanup
Add test case for issue #668: 401 Unauthorized detection in Codex err…
configurable error patterns for engines (#697)
pelikhan commentedon Sep 11, 2025
Should be flagged now with #697
Ryangr0 commentedon Sep 17, 2025
https://github.com/webgrip/n8n-application/actions/runs/17798306042/job/50591153315#step:11:163 I'm not seeing anything actionable on my end. Another thing to maybe think about: My org has a secret called OPENAI_API_KEY_CI. If somehow the name of the secret that's used to send to OAI was configurable, that would solve a lot of useless work / secret duplication. Or maybe let a manually defined env variable overwrite the secret env var used in the step if it's set?
It's still strange, because I'm 100% sure that the key I'm using is valid. So I'm just unsure on general on what's going on in my case.
pelikhan commentedon Sep 17, 2025
You could try to do
Should work, not tested though might refuse the override
Ryangr0 commentedon Sep 17, 2025
I'm pretty sure that won't work, this is the code
I tried putting it in env: on the rootlevel of the frontmatter segment, which results in
in the .lock file, but that doesn't do anything either I'm afraid, since the env var on the step itself is getting straight from the secret.
I'm not entirely discounting I'm just making a really stupid mistake.
EDIT:
I was wrong, putting
DOES result in
in the compiled version. If that's in the docs somewhere I must have missed it. My bad :)
pelikhan commentedon Sep 17, 2025
@dsyme did quite a bit of work with the latest codex so it might be good to upgrade (there will be some renaming breaking changes sorry).
1 remaining item
Ryangr0 commentedon Sep 17, 2025
is what I get when I compile after running
codex loginuses the secret. If it uses the environment variable instead, it's perfect. Right now it'll always use the secret, even though the point of the environment variable is to be able to serve exactly my use case ;)pelikhan commentedon Sep 17, 2025
It's not in the docs...
@copilot
Ryangr0 commentedon Sep 17, 2025
Thanks for the quick response! I didn't expect that. Just goes to show how much faster these tools let us iterate.
pelikhan commentedon Sep 17, 2025
Indeed login wasn't using the env var. patch coming
pelikhan commentedon Sep 17, 2025
Upgrade again
Ryangr0 commentedon Sep 17, 2025
It looks like there's a new bug. When compiling with 0.7.1, this is generated:
Then the following error comes up: https://github.com/webgrip/n8n-application/actions/runs/17803210894/job/50608277990#step:12:37
After I manually removed --search in the compiled .lock file, I saw a green agentic workflow for the first time :D.
Ryangr0 commentedon Sep 17, 2025
@pelikhan Just making sure you see this.
pelikhan commentedon Sep 17, 2025
@dsyme is
--searchonly available in later build?dsyme commentedon Sep 17, 2025
Ah sorry yes. Our tests in https://github.com/githubnext/gh-aw-test don't cover
web-search:I'll fix that
dsyme commentedon Sep 17, 2025
Actually strange, I see codex 0.36.0 supporting this
dsyme commentedon Sep 17, 2025
Well it's a bit whacky but you have to put that particular parameter before "exec"
We have considerable work to do to map the permissions model we use down to codex, which has its own sandboxing built in to the CLI tool.
Audit-only threat spec review: 2026-09-13 daily optimizer run