Summary
ocx account login produces no visible output for a long time when its stdout is consumed by another process, while redirecting the same command to a file returns the authorization URL immediately. In an automated/headless context this looks like a hang, and the natural operator reaction is to kill and retry — which discards a listener that is actually waiting for a callback.
Measured on opencodex 2.7.43 (@bitkyc08/opencodex), macOS, non-interactive shell.
Reproduction
- From a non-interactive shell, run
ocx account login with stdout piped into another command (for example a pager-like consumer).
- Observe: no output for roughly 70 seconds.
- Run the same command redirecting stdout to a file instead.
- Observe: the authorization URL appears in the file effectively immediately.
Expected
The authorization URL is emitted promptly regardless of whether stdout is a TTY, a pipe, or a file, so an automated caller can read it and drive the manual redirect-URL flow.
Why this matters beyond cosmetics
The manual redirect-URL path (ocx account code accepting a full redirect URL) is the only workable route when the browser is on a different machine than the CLI — remote host, SSH, or a headless worker. That path begins by reading the authorization URL from ocx account login. When that first step appears to hang under a pipe, the flow is usually aborted, and an authorization that a user already approved can be lost because the waiting listener was killed.
Related but distinct: #131 covered the GUI path lacking a manual code/redirect paste fallback. This report is about the CLI emitting its authorization URL late under a non-TTY stdout, which blocks the very fallback #131 established.
Additional observation — listener lifetime
In the same environment, the process waiting for the OAuth callback did not outlive the shell/session that started it. When an operator approves in a browser after that session ends, the approved authorization has nowhere to land. A documented, explicitly detachable listener lifetime — or a clear statement of how long the pending authorization remains claimable and how to resume it from a new process — would make the remote flow reliable. Happy to split this into its own issue if preferred.
Environment
opencodex 2.7.43- macOS, non-interactive shell, browser on a separate Windows host
- Codex account pool with auto-switch enabled
Summary
ocx account loginproduces no visible output for a long time when its stdout is consumed by another process, while redirecting the same command to a file returns the authorization URL immediately. In an automated/headless context this looks like a hang, and the natural operator reaction is to kill and retry — which discards a listener that is actually waiting for a callback.Measured on
opencodex 2.7.43(@bitkyc08/opencodex), macOS, non-interactive shell.Reproduction
ocx account loginwith stdout piped into another command (for example a pager-like consumer).Expected
The authorization URL is emitted promptly regardless of whether stdout is a TTY, a pipe, or a file, so an automated caller can read it and drive the manual redirect-URL flow.
Why this matters beyond cosmetics
The manual redirect-URL path (
ocx account codeaccepting a full redirect URL) is the only workable route when the browser is on a different machine than the CLI — remote host, SSH, or a headless worker. That path begins by reading the authorization URL fromocx account login. When that first step appears to hang under a pipe, the flow is usually aborted, and an authorization that a user already approved can be lost because the waiting listener was killed.Related but distinct: #131 covered the GUI path lacking a manual code/redirect paste fallback. This report is about the CLI emitting its authorization URL late under a non-TTY stdout, which blocks the very fallback #131 established.
Additional observation — listener lifetime
In the same environment, the process waiting for the OAuth callback did not outlive the shell/session that started it. When an operator approves in a browser after that session ends, the approved authorization has nowhere to land. A documented, explicitly detachable listener lifetime — or a clear statement of how long the pending authorization remains claimable and how to resume it from a new process — would make the remote flow reliable. Happy to split this into its own issue if preferred.
Environment
opencodex 2.7.43