# Codex authentication probe evidence

Both sides: Linux web development app, Chromium, 1280x800 CSS viewport at 2x device scale, light theme, real Codex CLI 0.167.1. Fresh independent databases, T3CODE_DEV_SEED=0, separate initially empty Codex homes. No model request was sent. API-key sign-in used a synthetic credential and tests only local CLI authentication recognition, as in the reported reproduction.

Base: 52d621a6f10f5a80ec433e3f3515eafbeabac74b
Head: c2f18912842f727875af198ac366b3e3bc846f2f

1. Configure one Codex instance with its empty home before server startup.
2. Open Settings > Providers. Confirm Not authenticated.
3. Record the provider card. Run the supplied driver against that checkout and Codex home.
4. Driver signs in using codex login --with-api-key, verifies codex login status, applies promptSuggestionsEnabled=true, waits 20 seconds, then applies backgroundActivity.profile=custom with overrides.providerHealthRefreshInterval=600000 and waits another 20 seconds.
5. Read the card and persisted server status snapshot after both waits. Neither Retry nor a provider-specific edit was used.

Before: error remains and checkedAt remains 19:30:57.298Z.
After: unrelated settings edit immediately re-probes at 19:32:31.886Z and card shows Authenticated · OpenAI API Key. The second settings edit retains the authenticated state.

Still captures were taken after two pixel-identical full screenshots more than 500 ms apart. Recordings cover both settings edits and both waits. Cropping preserves only the provider status region, removing machine identity, paths, and model lists. Captures are otherwise unmodified. Playback and frames were inspected before upload.

The scenario runner was not applicable: its documentation excludes provider-specific behavior, and Replay cannot exercise real Codex authentication recognition.

AI-assisted; verified with the tests and tools listed above.