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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   computer-use

   memory

   on Aug 24, 2026
2. MilkyWay008 commented on Aug 24, 2026

   

   MilkyWay008

   on Aug 24, 2026

   More actions

   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.
3. grevgeny commented on Aug 24, 2026

   

   grevgeny

   on Aug 24, 2026

   Author

   More actions

   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.
4. grevgeny commented on Aug 26, 2026

   

   grevgeny

   on Aug 26, 2026

   Author

   More actions

   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:

      401 Unauthorized: Missing bearer or basic authentication in header
      

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

      OK
      

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

      --config 'cli_auth_credentials_store="auto"'
      

      Result:

      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.
5. GeT-LeFt commented on Aug 27, 2026

   

   GeT-LeFt

   on Aug 27, 2026 – with ChatGPT Codex Connector

   More actions

   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.
6. KennyNoDie commented on Sep 1, 2026

   

   KennyNoDie

   on Sep 1, 2026

   More actions

   Independent reproduction on a newer desktop and bundled CLI version.

   Environment

   • ChatGPT desktop: 26.825.51511 (build 7377)
   • Bundled CLI: codex-cli 0.151.0-alpha.7.2
   • macOS
   • codex login status: Logged in using ChatGPT
   • cli_auth_credentials_store = "auto" is configured
   • ~/.codex/auth.json is absent before and after codex login status
   • Authentication is therefore Keychain-only

   Deterministic A/B reproduction

   I ran the bundled CLI in an empty temporary directory.

   Control:

   codex exec \
     --ephemeral \
     --ignore-user-config \
     --ignore-rules \
     --sandbox read-only \
     --skip-git-repo-check \
     "Reply exactly with ok"
   

   Result:

   Responses WebSocket: 401 Unauthorized
   Missing bearer or basic authentication in header
   HTTPS fallback: the same 401
   exit code: 1
   

   Candidate fix, with all other relevant inputs unchanged:

   --config 'cli_auth_credentials_store="auto"'
   

   Result:

   ok
   exit code: 0
   

   Real Computer History writer

   The automatic writer remains broken. A completed 10-minute segment ending at 2026-09-01T09:50:00Z contained 270 events. The internal writer then failed with repeated Responses WebSocket 401 errors, and ~/.codex/memories/extensions/skysight/resources still contained zero summary files.

   This independently confirms that the issue persists in 26.825.51511, and that explicitly forwarding the App-resolved credential-store mode fixes the bundled CLI invocation while the internal Computer History caller remains unchanged.

   No credential values or raw Computer History event contents were inspected or included.
7. josh-oai commented on Sep 14, 2026

   

   josh-oai

   on Sep 14, 2026

   More actions

   Thanks for the detailed reproduction. We’ve merged a fix for the Keychain authentication issue preventing Computer History summaries from starting, planned for an upcoming update. Please let us know if summaries still fail after updating.
8. KennyNoDie commented on Sep 15, 2026

   

   KennyNoDie

   on Sep 15, 2026

   More actions

   Retested after updating, including a full application restart.

   Environment

   • ChatGPT desktop: 26.908.70816 (build 9275)
   • Bundled CLI: codex-cli 0.154.0-alpha.6.2
   • Computer History plugin / Computer Use helper: 1.0.1001067 / 26.913.1001067
   • macOS
   • codex login status: Logged in using ChatGPT
   • cli_auth_credentials_store = "auto" is configured
   • ~/.codex/auth.json is still absent; authentication remains Keychain-only

   This is newer than the previously reported 26.825.51511 / 0.151.0-alpha.7.2 reproduction.

   Recording still works; summaries still do not start

   After enabling Computer History on the updated build, a complete 10-minute window closed normally:

   • 2026-09-15T04:00:00Z–04:10:00Z
   • eventCount=113

   The internal writer then failed at 12:10:34+0800 (~26.7s) with:

   codex exec failed ... HTTP error: 401 Unauthorized
   wss://api.openai.com/v1/responses
   

   ~/.codex/memories/extensions/skysight/resources remained empty.

   A later complete window (04:10:00Z–04:20:00Z, 193 events) failed the same way.

   Restart did not change the result

   ChatGPT was fully quit and reopened at 14:23:03+0800. The helper was a new process. Recording resumed. The first complete post-restart window:

   • 2026-09-15T06:20:00Z–06:30:00Z
   • eventCount=287

   failed at 14:30:28+0800 from the new helper process, again after ~27.0s, with the same codex exec failed ... HTTP 401 Unauthorized on wss://api.openai.com/v1/responses.

   resources/ is still empty after that window.

   Bundled CLI A/B on this updated build

   Control, empty temporary directory, bundled CLI:

   codex exec \
     --ephemeral \
     --ignore-user-config \
     --ignore-rules \
     --sandbox read-only \
     --skip-git-repo-check \
     "Reply exactly with ok"
   

   Result:

   Responses WebSocket: 401 Unauthorized
   Missing bearer or basic authentication in header
   HTTPS fallback: the same 401
   exit code: 1
   

   Candidate fix, all other relevant inputs unchanged:

   --config 'cli_auth_credentials_store="auto"'
   

   Result:

   ok
   exit code: 0
   

   The helper binary still contains --ignore-user-config and does not contain cli_auth_credentials_store.

   This update and a subsequent restart therefore do not yet include the caller-side fix. No credential values or raw Computer History event contents were inspected or included.