fix(cli): use shell-neutral guidance for overriding API key variables

[rohanpoudel2]

Fixes #33

Problem

When an API-key environment variable overrides a stored ChatGPT sign-in, the CLI suggests unset, which PowerShell does not provide. Windows users are told to run a command that does not exist, precisely when they are trying to resolve credential precedence.

There are two call sites in src/cli.ts, both reported in #33:

1. login status, which always names both variables:

   "To use a ChatGPT sign-in, unset OPENAI_API_KEY and CODEX_API_KEY.\n",

2. the login warning that a configured environment API key will keep taking precedence, which names only the variables actually set:

   `To use ${storedCredentials}, pass '--auth chatgpt' or run ` +
     `'unset ${configuredApiKeyVariables.join(" ")}'.\n`,

The same asymmetry appears in the docs. sdk/typescript/README.md gives Windows readers a PowerShell block for setting $env:OPENAI_API_KEY, but the instructions for making a stored ChatGPT sign-in the default offer only a bash unset OPENAI_API_KEY CODEX_API_KEY. Windows readers get a documented path in and no documented path out.

Change

Both CLI messages now use shell-neutral wording, following the direction suggested in the issue:

To use a ChatGPT sign-in, remove OPENAI_API_KEY and CODEX_API_KEY from the environment, then run the command again.

To use a stored ChatGPT sign-in, pass '--auth chatgpt' or remove OPENAI_API_KEY from the environment, then run the command again.

Neither message names a shell built-in, so there is no shell in which it is wrong. Variable-name casing is passed through unchanged, as before.

The second message builds its variable list at runtime and names whichever of OPENAI_API_KEY/CODEX_API_KEY are actually set, so the separator changed from " " to " and ". The environment lookup is case-insensitive (environmentApiKeyEntry in src/api.ts), so on a case-sensitive OS the list can in principle exceed two names and read "A and B and C". The message stays accurate and actionable in that case, and a general list formatter is not worth adding for it.

Separately, both READMEs now carry a PowerShell block next to the existing bash one, mirroring the existing "On Windows, set the API key in PowerShell" pattern:

Remove-Item Env:OPENAI_API_KEY, Env:CODEX_API_KEY -ErrorAction SilentlyContinue

Why not platform-detected guidance

#33 suggests a formatting helper with an injected platform value, printing unset on POSIX and Remove-Item Env: on Windows. That is more machinery for a worse result: process.platform describes the host, not the shell. It is wrong for PowerShell on Linux and macOS, for Git Bash, WSL, and MSYS on Windows, and for fish anywhere (fish has no unset; it uses set -e). Prose that names no shell is correct in all of them, and needs no injected platform to stay testable.

Why not naming every shell inline

Spelling out unset / Remove-Item Env: / set -e / set VAR= in one stderr line turns a two-line diagnostic into a shell cheat sheet, and still omits whichever shell the reader is using. The README is the right place for concrete per-shell commands; the CLI diagnostic states the goal.

Impact, stated plainly

Message text only. No behavioural, exit-code, or credential-precedence change: the conditions that select each message, the scanAuthentication result, and the exit codes are untouched. Anything grepping stderr for the literal unset guidance will stop matching — that is the point of the fix, and the new test enforces it.

Verification

• The three existing assertions on the old wording in tests-ts/cli-authentication.test.ts are updated to the new wording.
• A new regression test, uses shell-neutral guidance when an API key overrides the stored login, asserts that stderr from login status and from login (with one and with two variables set) never matches /\bunset\b/, /\bexport\s+\w+=/, or /\$env:/i, so this cannot silently regress into a single-shell dialect.

Measured on this branch:

$ pnpm run test          # full suite, with the fix
 739 pass
 5 skip
 0 fail
 5167 expect() calls
Ran 744 tests across 34 files.

$ bun test ./tests-ts/cli-authentication.test.ts     # with the fix
 23 pass
 0 fail

$ bun test ./tests-ts/cli-authentication.test.ts     # both messages reverted to `unset`
 19 pass
 4 fail

Reverting only the login message (leaving login status fixed) still fails the new test on its own, so it covers both call sites independently, not just the first one it reaches.

pnpm run types and pnpm run format are clean.

The PowerShell block is verified by reference to the Remove-Item / Env: provider contract, not executed — no PowerShell is available in the environment these checks ran in.

Left alone deliberately

• The #!/bin/sh wrapper the CLI generates for the Git hook is a real POSIX script, not user-facing shell advice.
• src/api.ts credential errors already say "set OPENAI_API_KEY or CODEX_API_KEY" without naming a shell built-in, so they need no change.
• The READMEs keep unset OPENAI_API_KEY CODEX_API_KEY in its explicitly labelled bash fence; the PowerShell block is added beside it rather than replacing it. cmd.exe is not covered, matching the existing house pattern of documenting Windows via PowerShell only.

[mldangelo-oai]

@codex review exact head 99d6f51

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

Reviewed commit: 99d6f51af8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Security review completed. No security issues were found in this pull request.

Reviewed commit: 99d6f51af8

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[slegarraga]

Reviewed the diff. The CLI guidance is now shell-neutral, the README documents PowerShell removal, and the tests assert that POSIX-only commands no longer leak into status or login output. The change stays scoped and looks correct.