Mac app 26.707.62119 does not sync chats, Projects or Memory while browser works normally #32845

Activity

1. nimishaaberia

   added

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

   on Jul 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jul 13, 2026
3. github-actions commented on Jul 13, 2026

   

   github-actionsbot

   on Jul 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Update gone bad #32834
   • Latest desktop version for MacOS, 26.707.62119 removes project and chat history #32800
   • Existing cloud Projects and chats do not sync in ChatGPT macOS app version 26.707.61608 #32718
   • Shared Projects missing from ChatGPT macOS app after update #32810

   Powered by Codex Action
4. nakiiimoon commented on Aug 30, 2026

   

   nakiiimoon

   on Aug 30, 2026

   More actions

   I hit what appears to be the same failure on macOS with ChatGPT Desktop 26.825.51511 (build 7377). The same account showed all Chats and Projects on the Web, but Desktop was empty.

   Symptoms

   • The remote ChatGPT host was detected.
   • observation_sequence kept increasing.
   • The remote catalog stayed at zero rows.
   • initial_build_complete stayed 0.
   • watermark_updated_at stayed NULL.
   • Rebuilding ~/.codex/sqlite/codex-dev.db did not fix it.
   • Codex itself still worked, so I did not reset the whole app or delete ~/.codex.

   The decisive log entry was:

   [WindowContext] Thread catalog sync failed errorMessage=net::ERR_CONNECTION_CLOSED
   

   There were also many sa_server_request_failed entries for ChatGPT backend routes. In my case the Mac was using Hiddify in TUN mode. Direct traffic was reset, while Hiddify's local mixed proxy was reachable at 127.0.0.1:12334.

   What fixed it

   I fully quit ChatGPT and relaunched it with an explicit local HTTP proxy, while disabling QUIC and HTTP/2:

   /Applications/ChatGPT.app/Contents/MacOS/ChatGPT \
     --proxy-server="http://127.0.0.1:12334" \
     --proxy-bypass-list="<-loopback>" \
     --disable-quic \
     --disable-http2

   Replace 12334 with the local mixed/HTTP proxy port shown by your proxy client. Before launching, verify that it is listening:

   nc -zv 127.0.0.1 12334

   This is different from merely enabling the macOS system proxy. On my machine, changing the system HTTPS proxy did not affect the already-running Electron process and did not advance the catalog state.

   After the explicit-proxy relaunch, the initial remote scan completed immediately:

   Metric	Before	After
   Remote local_thread_catalog rows	0	172
   initial_build_complete	0	1
   watermark_updated_at	NULL	populated
   last_full_reconciled_at	unset	populated

   The original ChatGPT history and Projects then appeared in Desktop, while the existing Codex task remained usable.

   Verification query

   sqlite3 -header -column "$HOME/.codex/sqlite/codex-dev.db" '
   SELECT
     h.host_kind,
     COUNT(c.thread_id) AS catalog_rows,
     s.initial_build_complete,
     (s.watermark_updated_at IS NOT NULL) AS has_watermark,
     s.observation_sequence
   FROM local_thread_catalog_hosts AS h
   JOIN local_thread_catalog_sync_state AS s USING (host_id)
   LEFT JOIN local_thread_catalog AS c USING (host_id)
   GROUP BY h.host_id
   ORDER BY h.host_kind;
   '

   Expected result: the chatgpt row has catalog_rows > 0, initial_build_complete = 1, and has_watermark = 1.

   I also checked both databases after recovery:

   sqlite3 "$HOME/.codex/sqlite/codex-dev.db" 'PRAGMA quick_check;'
   sqlite3 "$HOME/.codex/state_5.sqlite" 'PRAGMA quick_check;'

   Both returned ok.

   Why this appears to work

   Inspection of the bundled Desktop JS showed that the ChatGPT remote catalog begins with a paginated request equivalent to:

   GET /conversations?offset=0&limit=...&order=updated&is_archived=false&hide_snorlax=false
   

   The client calls completeScan() only after the page scan finishes. A network exception calls abortScan(), leaving the catalog empty, initial_build_complete = 0, and the watermark unset. The ChatGPT host then backs off before retrying. This exactly matched the observed database state.

   So, on this machine, the empty catalog was a consequence of the Electron/Chromium network path failing, not evidence of a corrupt catalog schema or lost cloud data. Forcing Electron through the known-working local HTTP proxy and disabling QUIC/HTTP2 allowed the initial pagination to complete.

   Safe backup before testing

   I recommend backing up the exact databases/configuration instead of deleting or resetting anything:

   stamp=$(date '+%Y%m%d-%H%M%S')
   backup_dir="$HOME/Desktop/ChatGPT-Codex-pre-proxy-relaunch-$stamp"
   mkdir -m 700 "$backup_dir"
   
   sqlite3 "$HOME/.codex/state_5.sqlite" ".backup '$backup_dir/state_5.sqlite'"
   sqlite3 "$HOME/.codex/sqlite/codex-dev.db" ".backup '$backup_dir/codex-dev.db'"
   cp -p "$HOME/.codex/auth.json" "$backup_dir/auth.json"
   cp -p "$HOME/.codex/.codex-global-state.json" "$backup_dir/codex-global-state.json"
   chmod 600 "$backup_dir"/*

   auth.json contains secrets. Keep the backup private and never attach it to a GitHub issue.

   Rollback

   The workaround does not edit the app bundle or database. To roll it back, quit ChatGPT and reopen it normally from /Applications. The command-line flags apply only to that launch.

   Notes and cautions

   • Do not delete all of ~/.codex, reset the whole app, fabricate catalog rows, or modify migration flags just to test this.
   • Rebuilding codex-dev.db was ineffective in this case because the newly created database encountered the same failed remote request.
   • I briefly saw Cloudflare challenge responses on some secondary routes after relaunch. The conversation catalog still completed, and the UI subsequently recovered. If Projects alone remain missing and logs show 403 for /gizmos/snorlax/sidebar, try a different, reputable VPN/proxy exit rather than editing the database.
   • This is a workaround for a proxy/TUN/Electron transport failure. It may not apply when logs show a different error.

   This looks closely related to #32845 and to the catalog state-machine symptoms in #35088, although #35088 did not report the same explicit network error.
5. shadowsfall118 commented on Sep 16, 2026

   

   shadowsfall118

   on Sep 16, 2026 – with ChatGPT Codex Connector

   Last edited by shadowsfall118

   More actions

   I found a different reproducible cause for incomplete ChatGPT history/Projects on macOS Desktop that may be useful alongside the proxy/TUN case above.

   My symptoms

   • Web showed the complete account history and Projects.
   • Desktop showed recent chats, but many older chats were missing from Project lists.
   • Desktop Search could still find some of those older chats.
   • Opening an old chat from Search did not add it to the Project list.
   • Sending a new message to that old chat immediately caused it to appear in the Project list.
   • Project renames synchronized correctly.
   • Rebuilding the local catalog produced a healthy database, but still only a partial history.

   The local catalog state was not the same as the proxy failure above. In my case:

   chatgpt catalog_rows = 110
   initial_build_complete = 1
   watermark populated
   PRAGMA quick_check = ok
   

   So the catalog sync was completing successfully rather than failing with ERR_CONNECTION_CLOSED.

   Important observation

   I tested an older conversation that was missing from its Project.

   Before interacting with it, there was no row for it in local_thread_catalog.

   Desktop Search could find and open the conversation, but it still did not create a local catalog row. After sending one harmless message, the conversation immediately appeared in local_thread_catalog with the correct server Project ID and then appeared normally in the Project list.

   That suggested Search can reach older server history, while the Project list depends on local_thread_catalog.

   Fresh catalog rebuild stopped at exactly 100 rows

   I then rebuilt only:

   ~/.codex/sqlite/codex-dev.db
   

   leaving the rest of ~/.codex intact.

   The fresh result was:

   chatgpt | 100 rows
   local   | 2 rows
   initial_build_complete = 1
   

   The oldest of those 100 ChatGPT rows was already about 36.9 days old.

   Bundled Desktop code appears to explain why

   In the current macOS app bundle, the ChatGPT catalog source is configured with:

   resumeOffsetPagination:e.hostKind===`chatgpt`,
   maxHistoryAgeMs:e.hostKind===`chatgpt`?720*60*60*1e3:void 0,
   failureBackoffMs:e.hostKind===`chatgpt`?J1e:void 0

   720 hours = 30 days.

   The same sync code uses a page size of 100 and stops a scan when a page contains an item older than maxHistoryAgeMs.

   The ChatGPT history source itself does support pagination beyond 100:

   GET /conversations?offset=<n>&limit=<page size>&order=updated&is_archived=false&hide_snorlax=false
   

   and advances by server offset/total.

   So 100 does not appear to be the intended total history limit. It is the page size. In my case the first 100-row page crossed the 30-day cutoff, so the initial scan completed without requesting the next page.

   Controlled test: patch only the 30-day cutoff

   To confirm this, I made a separate copy of the app, extracted app.asar, and changed only:

   maxHistoryAgeMs:e.hostKind===`chatgpt`?720*60*60*1e3:void 0

   to:

   maxHistoryAgeMs:e.hostKind===`chatgpt`?87600*60*60*1e3:void 0

   which is 10 years.

   I repacked the ASAR, ad-hoc signed the copied app, removed only the test codex-dev.db, and launched the patched copy so it would perform a fresh catalog build.

   Result:

   Stock fresh rebuild:   100 ChatGPT rows
   Patched fresh rebuild: 1197 ChatGPT rows
   

   All previously missing Project conversations then appeared normally, without touching or updating them individually.

   Extra confirmation

   After the patched app populated all 1197 rows, I quit it and launched the untouched stock /Applications/ChatGPT.app against the same database.

   The stock app retained:

   1197 total rows
   1197 active rows
   0 missing_candidate rows
   

   and the Projects remained complete.

   So the stock app can display and retain the full catalog once it exists. The issue appears to be the initial/full catalog scan stopping because of the hard-coded 30-day maxHistoryAgeMs cutoff.

   Practical workaround I used

   1. Back up ~/.codex/sqlite/codex-dev.db.
   2. Make a separate copy of ChatGPT.app.
   3. Patch only the ChatGPT maxHistoryAgeMs value in the copied app bundle.
   4. Repack and ad-hoc sign the copied app.
   5. Remove/rebuild only codex-dev.db while using the patched copy.
   6. Let the catalog fully populate.
   7. Quit the patched copy and return to the normal signed ChatGPT app.

   I am now using the normal stock app with the fully populated 1197-row catalog.

   Likely interpretation

   This looks like an intentional recent-history optimization with an unintended side effect for Projects. Project lists appear to depend on the local catalog, so older conversations can disappear from Desktop Projects even though the conversations and their Project membership still exist on the server.

   This is separate from the proxy/TUN failure documented above, where the catalog stayed at zero rows and initial_build_complete never completed. Both cases affect the same catalog machinery, but the failure modes are different.