Terminal ChatGPT login reuses desktop daemon outside the unlocked keyring session

Problem

With ChatGPT authentication enabled, coop codex can fail to save login credentials when a desktop Remote SSH app-server is already running. The terminal wrapper unlocks its private keyring session, but Codex reuses the existing daemon, whose keyring session is separate and unusable.

This terminal regression was discovered while troubleshooting #480. Track its fix separately from the broader desktop authentication and lifecycle integration.

Reproduction

Environment: macOS/Lima, rebuilt guest image, native Codex CLI 0.154.0, and ./target/release/coop reporting coop 0.6.0-dev (df5909c+dirty).

1. Configure [codex] auth = "chatgpt".
2. Connect the desktop app through Remote SSH, leaving its guest app-server running.
3. Run ./target/release/coop codex coop.
4. Enter the guest keyring password.
5. Select browser sign-in in the terminal and complete sign-in.

Observed browser result:

Sign-in completed but credentials could not be saved locally.
Error code: persist_failed
failed to write OAuth tokens to keyring: Platform secure storage failure: zbus error: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/secrets/collection/login”

Verified evidence

• The native installation layout was present and the managed app-server was running at version 0.154.0.
• The terminal process inherited the wrapper's private D-Bus session with COOP_CODEX_ACCOUNT_UNLOCKED=1.
• Its login collection reported Locked=false; a disposable non-secret write succeeded and was removed.
• The desktop daemon used the normal user D-Bus. That service advertised the login collection, but accessing it and attempting a disposable write returned the missing-object error.
• Unix socket inspection confirmed the terminal process connected to the existing app-server control socket.
• Codex 0.154.0 source permits implicit local-daemon reuse when there are no explicit configuration overrides.

A successful wrapper unlock therefore does not establish that the server handling terminal login uses the unlocked session.

User-confirmed workaround

Exit terminal Codex and launch with an explicit keyring override:

./target/release/coop codex coop -- -c 'cli_auth_credentials_store="keyring"'

The user confirmed this resolved the terminal login failure. In Codex 0.154.0, an explicit configuration override prevents implicit daemon reuse while retaining keyring storage.

Proposed scope and acceptance criteria

• Make ChatGPT-mode terminal launches use the keyring session unlocked by the wrapper, even when a desktop daemon already exists.
• Evaluate applying the explicit keyring override in the guest wrapper, including the codex-yolo entry point. Verify this version-dependent daemon-reuse behavior against supported Codex versions.
• Add a regression test with a pre-existing daemon on a separate unusable keyring session; ensure the test fails when the fix is removed.
• Preserve API-key mode, direct login/logout commands, explicit launch arguments, encrypted credential storage, and password handling.
• Do not silently fall back to plaintext credentials, copy host credentials, or persist the keyring password.
• Update terminal authentication documentation and validate backend-shared behavior on Lima and Firecracker, stating any untested gates.

Desktop managed-session design, reconnect/restart behavior, and registration remain in #480.

Start at the guest wrapper used by ./target/release/coop codex coop and the codex-yolo entry point, then verify how the explicit keyring override affects daemon reuse in supported Codex versions. Add a regression test with a pre-existing daemon on a separate unusable keyring session, and validate the behavior on Lima and Firecracker. Done means ChatGPT terminal login uses the unlocked session without changing API-key, direct auth, credential-storage, or password behavior.