ci: rename base-url secret to OPENAI_BASE_URL + gitignore stray png

[guohai]

What

• codex-review: provider endpoint secret renamed CODEX_OPENAI_BASE_URL → OPENAI_BASE_URL (in the workflow and as a repo secret; same value).
• .gitignore: ignore audio_pcm_waveform.png (a local test artifact), next to the existing dots-break.png.

Doubles as verification of #31

This PR does not touch claude-code-review.yml, so claude-review validates against main and runs with the newly-merged track_progress + use_sticky_comment — a posted summary comment here confirms #31 works. codex-review exercises the renamed secret.

Follow-up

After merge, the old CODEX_OPENAI_BASE_URL secret is removed.

Generated with SMT smt@agora.io

[github-actions]

🤖 Codex Code Review

No findings.

• The workflow change only renames the secret reference at .github/workflows/codex-code-review.yml:35; it does not broaden permissions or expose credentials.
• .gitignore:25 adds a local PNG artifact pattern and has no security, logic, or performance impact.
• Residual risk is operational: the OPENAI_BASE_URL repo secret must exist with the same trailing-slash format expected by the existing ... }}v1/responses concatenation.

[github-actions]

🤖 Codex Code Review

No findings.

The changes look low-risk: the secret rename is applied consistently, the endpoint construction now handles a missing trailing slash, and the .gitignore addition is scoped to the intended local artifact.

[github-actions]

🤖 Codex Code Review

No findings.

The changes are limited to the secret name used for responses-api-endpoint and ignoring a local PNG artifact. I don’t see introduced security, logic, performance, or maintainability issues in this diff. Residual risk is operational: the workflow depends on OPENAI_BASE_URL being configured with the documented trailing slash before/at merge time.

[github-actions]

🤖 Codex Code Review

No findings.

The changes look low-risk: the workflow now references secrets.OPENAI_BASE_URL with an explicit /v1/responses suffix, and .gitignore only adds a local PNG artifact. I don’t see security, logic, performance, or maintainability issues introduced by this PR.

Residual risk: the workflow depends on the repo secret being renamed before/with merge; if OPENAI_BASE_URL is missing or includes an unexpected trailing slash, the Codex review step may fail or use a doubled slash, but that’s operational rather than a code defect.

[claude]

Claude finished @guohai's task in 1m 2s —— View job

---

Code Review — PR #32

• Read the diff against origin/main
• Review .github/workflows/codex-code-review.yml
• Review .gitignore
• Post findings

Verdict: LGTM. This is a low-risk CI/secret-rename + gitignore change. The diff is internally consistent and the trusted-author gate is a genuine security improvement. No blocking issues.

---

What changed

1. Secret rename CODEX_OPENAI_BASE_URL → OPENAI_BASE_URL, with the endpoint construction switching from trailing-slash-on-secret (…BASE_URL }}v1/responses) to leading-slash-in-path (…BASE_URL }}/v1/responses). Consistent — the slash moved from the secret value into the template, so the resulting URL is unchanged provided the new secret has no trailing slash (which the inline comment documents).
2. Trusted-author gate added to the codex-review job — a real hardening, not just a rename (see below).
3. .gitignore ignores audio_pcm_waveform.png next to the existing dots-break.png. Fine.

Observations (non-blocking)

1. Endpoint is brittle to the secret's slash format — by design, but flag it.
responses-api-endpoint: ${{ secrets.OPENAI_BASE_URL }}/v1/responses (line 45) assumes the secret has no trailing slash. If someone later sets the secret with a trailing slash you get a doubled //v1/responses. There's no normalization, so correctness depends on an out-of-band convention documented only in a comment. Acceptable under KISS, and the codex self-reviews above already confirmed the value format — just make sure the renamed repo secret was stored without the trailing slash when it was created.

2. The author-association gate is the right call, and worth keeping in sync.
The prompt interpolates untrusted pull_request.title/body (lines 51–52) into the model input, and final-message is posted verbatim (line 79). Restricting the job to OWNER/MEMBER/COLLABORATOR closes the fork/untrusted-PR prompt-injection-to-exfiltration path, and the inline comment explains the reasoning well. Two things to keep in mind:

• This mirrors claude-code-review.yml — keep both gates identical if either changes, since they share the same threat model.
• Side effect: bot/Dependabot/first-time-contributor PRs (CONTRIBUTOR/NONE) will now silently skip codex review. That's the intended trade-off; noting it so it isn't surprising later.

3. Naming. OPENAI_BASE_URL happens to be the conventional env var the OpenAI SDK auto-reads. Here it's only a GitHub secret referenced explicitly in responses-api-endpoint (not exported to the step env), so there's no accidental-pickup conflict. The shorter name is actually cleaner than the old prefixed one.

Note on scope

The two changed files are both under .github/workflows/ and the repo root — I can review but not modify workflow files (GitHub App workflow-write restriction). No changes were requested here anyway; this is review-only.

[github-actions]

🤖 Codex Code Review

Findings

• Low: .github/workflows/codex-code-review.yml:14 — The new author gate does not actually exclude fork PRs from trusted users. A COLLABORATOR/MEMBER can open a PR from a fork, the job condition passes, but repository secrets are normally unavailable to pull_request workflows from forks, so openai-api-key / responses-api-endpoint may be empty and the review job fails. If the intent is “fork PRs don’t run,” add a same-repo guard such as github.event.pull_request.head.repo.full_name == github.repository or explicitly handle missing secrets.

No security issue found with the secret rename itself, and the .gitignore change looks fine.