[macOS][Computer History] Recorder creates Skysight segments but 10-minute summaries never start

55 segment dirs but zero files under ~/.codex/memories/extensions/skysight/resources means recording is fine and the summarizer helper is the part that never runs. I'd check log show --last 2h --predicate 'process CONTAINS "codex_chronicle" OR eventMessage CONTAINS "skysight"' to see if the helper even launches and what it errors on, plus ~/.codex/log and ~/Library/Logs right at a 10-minute boundary. Also worth confirming ~/.codex isn't symlinked oddly and running spctl -a -vv against the codex_chronicle binary in case Gatekeeper/TCC is blocking it, toggling Computer History off and on resets the summarizer state if nothing else shows.

Thanks — I ran the suggested checks:

• The macOS unified log for the last three hours contains no actual codex_chronicle launch or Skysight runtime messages; it only contains the diagnostic log show queries themselves.
• ~/.codex is a normal directory, not a symlink.
• codesign --verify --strict reports that codex_chronicle is valid on disk and satisfies its Designated Requirement.
• Gatekeeper accepts the parent ChatGPT.app as a Notarized Developer ID application.
• Toggling Computer History off and on had already been tried before filing this issue. A full application restart and update were also tried, with no change.
• Computer History is still running and producing fresh event-stream segments, while the Skysight resources directory remains empty.

This further narrows the failure to the scheduler/queue before the summarizer helper is launched, rather than the recorder or an apparent Gatekeeper/signature failure.

Update: I now have a deterministic root-cause reproduction. Please disregard my earlier conclusion that the failure occurs before the summarizer launches.

Current versions:

• ChatGPT desktop: 26.820.60940
• Bundled CLI: codex-cli 0.150.0-alpha.8

The recorder remains healthy and produces fresh Skysight segments. The scheduler also launches the memory writer approximately every ten minutes. However, ten recent writer attempts failed identically with:

401 Unauthorized: Missing bearer or basic authentication in header
wss://api.openai.com/v1/responses

The writer subsequently falls back to HTTPS and receives the same 401. Consequently, it produces no output and ~/.codex/memories/extensions/skysight/resources remains empty.

The generated writer command includes:

codex exec --ephemeral --ignore-user-config --ignore-rules --sandbox read-only ...

I reproduced the failure outside Computer History using the bundled CLI and the same relevant flags:

1. With --ignore-user-config:

``text
401 Unauthorized: Missing bearer or basic authentication in header
``

1. Removing only --ignore-user-config:

``text
OK
``

1. Retaining --ignore-user-config but adding:

``text
--config 'cli_auth_credentials_store="auto"'
``

Result:

``text
OK
``

Relevant local state:

• codex login status reports Logged in using ChatGPT.
• cli_auth_credentials_store = "auto" is configured.
• Authentication is available through Keychain; there is no auth.json file.
• The writer environment contains no OPENAI_API_KEY, CODEX_API_KEY, or API base-URL override.

The causal chain therefore appears to be:

Skysight scheduler launches writer
→ --ignore-user-config discards cli_auth_credentials_store="auto"
→ credential storage falls back to the file default
→ no auth.json exists
→ request is sent without an Authorization header
→ writer exits without output
→ no 10-minute summary is written

This also conflicts with the CLI flag’s documented contract that authentication still uses CODEX_HOME:

• codex-rs/exec/src/cli.rs
• codex-rs/config/src/config_toml.rs

A narrow fix for the internal Computer History caller would be to retain --ignore-user-config while explicitly passing the App-resolved credential-store mode, for example:

--config 'cli_auth_credentials_store="auto"'

A regression test should cover an isolated internal writer with credentials available only through a mocked Keychain, no auth.json, and ignored user configuration. It should verify that the request is authenticated and that a 10min summary resource is written.

No settings or application files were changed during this investigation.

Thanks for the deterministic authentication finding. I reproduced the same user-visible failure on the same current desktop/CLI versions, but my local authentication state differs in an important way.

Environment

• ChatGPT desktop: 26.820.60940 (build 7119)
• Bundled CLI: codex-cli 0.150.0-alpha.8
• Computer History plugin: 1.0.1000816
• Computer Use service: 26.819.1000816
• Authentication status: Logged in using ChatGPT

Different authentication state

In this reproduction, $CODEX_HOME/auth.json is present and has existed since August 2. I inspected structure only, not credential values:

• mode: 0600
• auth_mode: chatgpt
• token object contains the expected access, refresh, ID-token, and account-ID keys
• OPENAI_API_KEY is null
• no OPENAI_API_KEY, CODEX_API_KEY, or API base-URL override is present in the environment
• cli_auth_credentials_store is not explicitly configured in config.toml

Running codex login status refreshed the auth file timestamp. The desktop app refreshed it again approximately 19 minutes later, confirming that the ChatGPT credential set was still active. Despite that refresh, summary generation did not recover.

Controlled observations

I also tested the previously suspected CLI-path issue. For one controlled run, both the ChatGPT process and SkyComputerUseService inherited:

CODEX_CLI_PATH=/Applications/ChatGPT.app/Contents/Resources/codex

That run lasted about 39 minutes and crossed multiple complete event windows. Representative completed segments contained 96, 124, and 171 eligible events. No summary resource was generated, so the CLI-path hypothesis is ruled out for this reproduction.

After the authentication refresh, I observed another complete window:

startedAt: 2026-08-27T09:50:00Z
endedAt:   2026-08-27T10:00:00Z
eventCount: 76
suppressedEventCount: 7

By 10:01:57Z:

• $CODEX_HOME/memories/extensions/skysight/resources still contained zero files;
• no codex exec, codex_chronicle, or other summary process was observed by periodic process sampling;
• no summary start, completion, failure, or missing-authentication entry appeared in the macOS unified log;
• the active Codex log database contained no Chronicle/Skysight/summary/401 entries.

The bundled codex_chronicle binary does contain the expected internal flags:

--ephemeral
--ignore-user-config
--ignore-rules
--sandbox read-only

Current conclusion

This is the same recorder-healthy / resources-empty symptom, but I cannot confirm the same local 401 path because auth.json exists, is actively refreshed, and no independent 401 Unauthorized evidence is emitted locally.

It may be a second silent failure mode, or the internal writer may still be failing to consume the available ChatGPT credentials before it emits observable logs. Please consider exposing the writer launch result and stderr/exit reason in diagnostics so these cases can be distinguished.

No credential values, raw event contents, or private paths are included here.