[Bug]: /gpt-account add renders the OpenAI Codex login-method select as an empty text input (Unknown OpenAI Codex login method:)

[code-yeongyu]

What happened?

Reported in the Jobdori Hub Discord (2026-09-08; ihurag on Linux, reproduced by typeey on Linux) against OmO Native 5.0.0-0.beta.48 / senpi 2026.9.7-2:

• /gpt-account add prints Select OpenAI Codex login method: but renders an empty text input instead of the two options.
• Pressing Enter sends an empty string and the command fails with Error: Unknown OpenAI Codex login method:.
• Typing device_code into the empty input starts the device flow, but the notice only shows the verification URL — the user code is never displayed, so the flow cannot be completed.
• Typing browser shows the authorize URL as a plain wrapped notice and nothing opens the browser, although the provider's instruction says "A browser window should open".
• In the same environment /login → OpenAI Codex correctly shows Browser login (default) / Device code login (headless).

Steps to reproduce

1. senpi (or OmO Native beta.48) in a terminal.
2. /gpt-account add + Enter.
3. Observe the empty input under Select OpenAI Codex login method:; press Enter → Error: Unknown OpenAI Codex login method:.

Root cause

packages/coding-agent/src/core/extensions/builtin/gpt-account.ts (addAccount, lines 50-58) passes an AuthInteraction whose prompt relays every AuthPrompt to ctx.ui.input(prompt.message):

prompt: async (prompt) => {
    const answer = await ctx.ui.input(prompt.message);
    if (answer === undefined) throw new Error(LOGIN_CANCELLED_MESSAGE);
    return answer;
},
notify: (event) => ctx.ui.notify(authEventMessage(event), "info"),

• prompt.type === "select" (the login-method chooser emitted by packages/ai/src/auth/oauth/openai-codex.ts:499-506) is shown as a text input; prompt.options are ignored, so the user cannot see or pick an option, and the empty answer reaches the provider's Unknown OpenAI Codex login method guard.
• prompt.placeholder and the per-prompt prompt.signal are ignored, so the manual_code dialog is not dismissed when the local callback server wins the browser race.
• authEventMessage drops userCode from device_code events and never opens the browser for auth_url.

The correct routing already exists for /login (core/auth-storage.ts:719-731 → onSelect; modes/rpc/login-prompts.ts) — the extension command simply does not use it. claude-sdk-oauth/account-command.ts addAccount has the same relay shape (its provider flow does not emit a select prompt today, but it shares the placeholder / signal / browser gaps).

Expected behavior (ideal end state)

1. /gpt-account add shows the login-method chooser as a real selector (ctx.ui.select with the option labels, chosen label mapped back to the option id) — the same two choices as /login.
2. text / secret / manual_code prompts go to ctx.ui.input(message, placeholder, { signal }), where the signal combines the command signal and the provider's per-prompt signal, so the manual-code dialog closes by itself once the callback server completes the login.
3. device_code events display the verification URL and Enter code: <userCode>.
4. auth_url events open the browser in the TUI (same as /login) and still print the URL as a fallback.
5. The relay lives in one shared builtin helper used by both /gpt-account add and /claude-account add, with regression tests in test/suite/account-extension.test.ts.

Version

senpi 2026.9.7-2 (OmO Native 5.0.0-0.beta.48), reproduced on Linux and macOS.

Plan

Fix lands from branch fix/gpt-account-login-method-select; progress (RED tests, fix, real-TUI verification, PR) will be reported in comments on this issue.

Discord thread: https://discord.com/channels/1452487457085063218/1490539106797621259/1546781611930951741

[code-yeongyu]

Progress: fix is up as #1486

Root cause (confirmed in code): gpt-account.ts addAccount relayed every AuthPrompt to ctx.ui.input(prompt.message). The OpenAI Codex flow's first prompt is { type: "select", options: [browser, device_code] }, so the TUI drew an input box with the select's title and no options; Enter submitted "", which the provider rejects with Unknown OpenAI Codex login method:. The same relay ignored placeholder and the per-prompt signal, and authEventMessage dropped userCode from device_code events and never opened the browser.

Ideal end state implemented (branch fix/gpt-account-login-method-select):

1. One shared relay, builtin/oauth-login-interaction.ts → createExtensionLoginInteraction(ctx, …), used by both /gpt-account add and /claude-account add.
2. select → ctx.ui.select over the option labels, mapped back to the option id — the same two choices /login shows.
3. text/secret/manual_code → ctx.ui.input(message, placeholder, { signal }); the signal combines the command signal and the provider's per-prompt signal, so the paste-the-code dialog closes on its own when the local callback server finishes the login.
4. device_code → notice with the verification URL and Enter code: <userCode>.
5. auth_url → opens the browser in the TUI (as /login does) and prints the URL as a fallback; RPC/desktop clients keep the notice only.

Evidence so far

• RED (before the fix, new tests only): 5 failed / 14 passed — the select prompt was recorded as { kind: "input", title: "Select OpenAI Codex login method:" }, the device-code notice lacked the code, the manual-code dialog had no placeholder/signal, no browser launch.
• GREEN: 36 passed across account-extension, gpt-account-extension, gpt-account-add, claude-sdk-oauth-account-command, rpc-login-interactive-prompts, app-server-account.
• tsc --noEmit clean, root npm run check passed, scripts/check-pr-changelog.mjs PASS.

Next: real-TUI run of /gpt-account add from the built CLI (screenshot of the selector + device-code notice), then CI → merge. Until the release that carries this lands, the workaround remains /login → Sign in with an account → OpenAI Codex → Device code login (headless).

[code-yeongyu]

Real-TUI verification (built dist/cli.js from #1486, fresh SENPI_CODING_AGENT_DIR, macOS, 120x36 PTY)

/gpt-account add + Enter now renders the selector:

 Select OpenAI Codex login method:
 → Browser login (default)
   Device code login (headless)
 ↑↓ navigate  enter select  esc/ctrl+c cancel

Down + Enter on Device code login (headless) prints the verification URL together with the user code (code masked here):

 Open this URL to authorize OpenAI Codex OAuth:
 https://auth.openai.com/codex/device
 Enter code: XXXX-XXXXX
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
❯
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Screenshots (xterm.js render of the raw PTY stream, posted to the reporters' Discord thread): selector · device code

Test evidence: RED 5 failed / 14 passed before the fix → GREEN 36 passed after; tsc --noEmit clean; root npm run check passed; changelog gate PASS. Waiting on PR CI, then merging.

[code-yeongyu]

Resolved

Merged via #1486 (merge commit a1ac4014876b14c592af420efb29601058d5d600), which auto-closed this issue.

State on main now

• /gpt-account add shows Browser login (default) / Device code login (headless) as a selector; the empty-input + Unknown OpenAI Codex login method: path is gone.
• Device code: notice prints the verification URL and Enter code: <code>.
• Browser login: the TUI opens the browser and prints the URL as a fallback; the paste-the-code dialog closes on its own once the local callback completes.
• /claude-account add shares the same relay.

Gate review: independent reviewer re-ran the six account/login suites (36 passed), mutation-probed the selector test (routing select back to ui.input fails it), and checked the real-TUI transcripts — APPROVE, no blockers.

Availability: the fix is in [Unreleased] of packages/coding-agent/CHANGELOG.md; it ships with the next senpi release after 2026.9.7-2 and reaches OmO Native once omo pins that senpi version. Until then: /login → Sign in with an account → OpenAI Codex → Device code login (headless).