Codex 側邊欄突然空了？這個工具能救回來
整理版優先睇
Codex切API後側邊欄歷史消失？開源工具codex-history-share幫你同步返
呢篇文章係由一個叫「小石學長」嘅作者寫嘅，佢係一個重度Codex用家。佢遇到一個好煩嘅問題：Codex由ChatGPT登錄切到API模式之後，左側邊欄嘅歷史會話突然全部唔見曬。模型正常、配置冇問題，但係工作記錄好似被清空咁。佢第一時間想做嘅唔係寫code，而係搞清楚記錄係咪真係冇咗。
查完之後發現，記錄仲喺度，只係當前provider睇唔到舊provider嘅索引。呢個問題唔係技術報錯，而係狀態管理嘅問題。作者決定將呢個痛點變成開源工具，就係codex-history-share。佢復用咗Dailin521嘅codex-provider-sync做底層同步，然後補咗產品化體驗，令到用戶可以簡單用幾條命令修復可見性。
整體結論係：呢啲小工具雖然唔宏大，但係可以解決具體嘅摩擦，令到工作流少斷一次。作者強調邊界清楚比口號重要，工具唔係魔法，只係幫你將本地歷史喺多provider之間保持可見。如果成日切API嘅人，呢個工具會好有用。
- Codex切換provider後側邊欄歷史消失，但記錄其實冇丟，只係被當前provider索引擋住。
- 問題根源係provider metadata：舊會話帶住舊provider標記，唔會自動顯示喺新provider下面。
- 解決方法係用codex-history-share同步：先codex-history status確認分佈，再用codex-history sync同步。
- 工具嘅核心設計係補體驗：複用已有項目嘅底層同步，加上watch同install-agent做到後台自動修復。
- 邊界提醒：呢個工具唔能夠跨賬號無損續聊，加密內容仲係綁死賬號，定位只係本地歷史可見性修復。
codex-history-share
開源CLI工具，用嚟同步Codex歷史會話到當前provider，支援status、sync、watch、install-agent同export命令。
問題背景：側邊欄點解突然空了？
作者係重度Codex用家，佢用咗一個provider切換工具將Codex由ChatGPT登錄切到API模式。切完之後，右下角模型正常、提問正常、API正常，但左側邊欄嘅歷史會話突然全部消失。呢個感覺唔係技術報錯，而係工作記錄被清空嘅不安。
左側邊欄對重度使用者嚟講係項目時間線
佢第一反應唔係寫code，而係想確認記錄係丟咗定係只係睇唔到。查完之後發現記錄仲喺度，問題出喺provider metadata。
根本原因：provider metadata令舊會話被視角擋住
Codex嘅歷史會話主要喺幾個本地檔案：~/.codex/sessions、~/.codex/archived_sessions、~/.codex/state_5.sqlite同~/.codex/session_index.jsonl。當你由一個provider切到另一個，舊會話仲喺度，但帶住舊provider標記。Codex只會讀當前provider嘅索引，所以舊會話好似企喺另一扇門後面。
- 1 本地歷史檔案位置：~/.codex/sessions
- 2 存檔會話：~/.codex/archived_sessions
- 3 SQLite狀態庫：~/.codex/state_5.sqlite
- 4 會話索引：~/.codex/session_index.jsonl
工具設計：唔係重寫輪子，而係補體驗
作者冇從零寫起，而係復用咗Dailin521嘅codex-provider-sync項目，佢已經處理咗掃描rollout檔案、更新SQLite、修復項目可見性、備份同恢復等底層麻煩。作者嘅角色係將呢啲底層能力產品化，補上用戶體驗。
做工具有時候最重要係判斷邊度該複用，邊度該補體驗
- 先用codex-history status確認歷史分佈喺邊啲provider下面
- 再用codex-history sync同步舊歷史到當前provider
- 經常切API嘅人可以裝watch指令或者install-agent（macOS後台常駐），以後自動修復
- 最後codex-history export可以導出標題、項目路徑、首條用戶消息作為保險
邊界清楚：呢個工具唔係魔法
作者好坦白講咗邊界：呢個工具可以令歷史會話重新顯示喺左側邊欄，但唔能夠將舊會話嘅encrypted_content重新加密到另一個賬號或provider。所以部分舊會話睇得到，但繼續對話仲有機會遇到invalid_encrypted_content。
作者認為，Agent時代真正值錢嘅工具，好多時候唔係生成好型嘅嘢，而係令工作流少斷一次。少斷一次，就多一口氣。
即刻可以試：幾條命令搞掂
如果你都遇到類似問題，可以就咁喺Terminal執行以下命令。首先安裝工具：
npm install -g git+https://github.com/Standed/codex-history-share.git
codex-history syncmacOS用戶想後台自動修復可以裝agent：
codex-history install-agent想導出索引做備份：
codex-history export第一版只係CLI，但核心功能已經穩陣
尋日凌晨，我遇到一個好細，但好煩嘅問題。
Codex 切咗去 API 之後，左邊側欄以前用 ChatGPT 登入嗰啲歷史會話，突然間睇唔到。
模型用得正常，配置冇問題，項目都仲喺度。
就係左邊嗰排好熟嘅聊天記錄，突然空咗。
呢件事最煩嘅地方唔係技術報錯，而係嗰種工作記錄俾人清空嘅感覺。
對重度用 Codex 嘅人嚟講，左邊側欄唔係普通聊天記錄。
佢更加似項目嘅時間線。
一個功能點解咁改，一個 bug 當時點樣排查，一個工具點樣砌起嚟，好多判斷都藏喺呢啲舊會話裏面。
所以我第一個反應唔係寫 code。
我第一時間想確認一件事：呢啲記錄係真係冇咗，定係只係睇唔到？
後尾查落去，答案係後者。
記錄仲喺度，只係當前 provider 睇唔到舊 provider 嘅索引。
於是乎我哋順手將呢個問題整咗一個開源工具。
項目地址係 https://github.com/Standed/codex-history-share
安裝咗之後先 run 呢兩行。
因為佢唔係為咗曬技術而出世，而係由一個真實嘅卡點度整出嚟嘅。
一開始，我以為只係賬號問題
嗰陣我用咗一個 provider 切換工具，將 Codex 由 ChatGPT 登入切到 API 模式。
切完之後，右下角模型正常，提問正常，API 都正常。
但左邊側欄突然間變得好空。
呢個時候最容易誤判，以為係賬號切換搞到雲端歷史冇同步，或者 Codex 清咗舊記錄。
但係本地一查，文件其實仲喺度。
Codex 嘅歷史主要喺下面呢幾個位置。
· ~/.codex/sessions
· ~/.codex/archived_sessions
· ~/.codex/state_5.sqlite
· ~/.codex/session_index.jsonl
真正嘅問題喺 provider metadata。
你以前用 openai ，而家轉咗用 OpenAI 、 crs ，或者某個中轉 API。
歷史會話仲喺本地，但佢帶住舊 provider 嘅標記。
Codex 而家只係讀當前 provider 下面嘅索引，於是舊會話好似企咗喺另一道門後面。
佢唔係冇咗，只係俾而家嘅視角擋住咗。
呢個發現幾得意。
好多 AI 工具嘅問題，最後唔係模型能力問題，而係狀態管理問題。
賬號、provider、token、會話、索引、加密內容、項目路徑。
每樣嘢單獨睇都合理，但係佢哋組合埋一齊，就會喺某個凌晨將你嘅側欄變成空白。
我哋冇重新整過個輪
呢度要感謝現有項目 https://github.com/Dailin521/codex-provider-sync 佢已經將底層最麻煩嘅事處理咗，包括掃描 rollout 文件、更新 SQLite、修復項目可見性、創建備份同支援恢復。
所以我哋冇由零寫過。
整工具有時候最重要嘅唔係證明自己咩都識寫，而係判斷邊度應該重用，邊度應該補充體驗。
底層同步已經有人做得好好，咁我哋就將佢產品化啲。
於是乎有咗 codex-history-share 。
第一版冇做到好複雜，我只係想將最痛嘅地方補返。
你可以先用 codex-history status 睇嚇，確認歷史分佈喺邊啲 provider 下面。
睇清楚之後，再用 codex-history sync 將舊歷史同步到當前 provider。
如果你成日切 API、切賬號，手動同步就唔夠用，所以佢又補咗 watch 同 install-agent 。
前者睇實本地配置有冇變，後者喺 macOS 背景長駐，盡量令呢件事以後唔好再打斷你。
最後仲有一個 export 。
佢唔會令舊會話跨賬號無損咁繼續傾，但至少可以將標題、項目路徑、第一條用戶消息呢啲索引導出嚟，俾自己嘅工作記憶留一份保險。
我自己最在意嘅其實係 watch 同 install-agent 。
手動整一次當然可以，但如果一個工具每次換賬號都要你諗起手動整，佢就未真正融入工作流程。
好嘅小工具應該似一個安靜嘅墊片。
你唔使成日諗起佢，但佢喺度，將兩個容易錯位嘅地方墊平。
有個邊界一定要講清楚
呢個工具唔能夠變魔法。
佢可以令歷史會話重新顯示喺左邊側欄，但係冇辦法將舊會話入面嘅 encrypted_content 重新加密到另一個賬號或 provider。
所以有啲舊會話可以睇到，但繼續傾偈嗰陣，仍然可能遇到 invalid_encrypted_content 。
呢個唔係工具偷懶，而係加密內容同賬號、provider 綁定之後嘅邊界。
而家好多 AI 工具喺宣傳嗰陣，成日鍾意將做到同穩定做到撈埋一齊講。
但係真正整俾人長期用嘅工具，邊界比口號重要。
所以呢個項目嘅定位唔係跨賬號無損續聊神器。
更準確啲講，佢解決嘅係本地歷史可見性：令 Codex 本地歷史喺多 provider、多登入方式之間盡量保持側欄可見，並提供備份、恢復同導出。
呢句說話聽落冇咁性感。
但佢真係可以解決一個痛點。
一個小工具背後嘅判斷
呢件事做完之後，我有一個好強嘅感受。
以後 AI Agent 嘅生態裏面，會出現越來越多呢類小工具。
佢哋唔一定宏大，亦唔一定有華麗嘅界面，甚至第一版可能得幾條命令。
但佢哋會解決一啲好具體嘅摩擦。
例如換賬號後歷史睇唔到，本地狀態唔同步，多工具之間上下文斷開。
再深入啲，係某個配置一改，成個工作流程突然失憶；一個 Agent 做完嘢，另一個 Agent 接唔上。
呢啲問題睇起嚟都好細。
但係真正每日用 AI 返工嘅人知道，小摩擦積累起嚟，就係生產力嘅漏水位。
你唔係俾一個大問題拖慢嘅。
你係俾十幾個小斷點一點點打斷嘅。
而 Agent 時代真正值錢嘅工具，好多時候唔係幫你生成一個好型嘅嘢，而係令你嘅工作流程少斷一次。
少斷一次，就多一啖氣。
如果你都遇到呢個問題
你可以直接試呢幾行。
如果你用 macOS，而且成日切換 API 或賬號，可以裝背景監聽。
目前第一版偏向 CLI。
Skill 都一齊放咗入倉庫，之後可以俾 Agent 自動跟呢個流程幫用戶診斷同修復。
EXE、DMG、GUI 呢啲唔係做唔到，但我想先將最核心嘅嘢行穩。
工具呢樣嘢，我而家越來越唔信第一版就要完整。
好多時候，第一版只要真實、可用、邊界清楚，就已經好好。
寫喺最後
今次最打動我嘅，其實唔係寫咗幾多 code。
而係呢個過程好似將來我哋同 AI 一齊做嘢嘅樣。
一個人遇到問題，講出嚟。
AI 去查本地狀態，讀開源項目，確認邊界，封裝 CLI，寫文檔，跑測試，推 GitHub，發 Release。
中間冇宏大嘅發佈會，亦冇乜顛覆行業嘅大詞。
就係一個小問題，俾人認真對待，然後變咗一個其他人都用得嘅工具。
我覺得呢個就係智能體工坊最應該做嘅嘢。唔係每日追住大模型參數跑。而係將啲真實工作裏面卡住人嘅地方，一個一個磨平。
技術最後會唔會改變世界，我唔知。
但佢至少可以將我哋自己嘅工作枱，擦得亮少少。
覺得有用嘅話，可以將呢個工具轉俾正在搞 Codex 嘅朋友。
好多人唔係唔識用 AI，只係俾呢啲小卡點攔住咗。
昨天凌晨，我遇到一個很小，但很煩的問題。
Codex 切到 API 之後，左側邊欄以前用 ChatGPT 登錄時的歷史會話，突然看不到了。
模型能正常用，配置也沒問題，項目也還在。
就是左邊那一排熟悉的聊天記錄，突然空了。
這件事最煩的地方不是技術報錯，而是那種工作記錄被清空的感覺。
對重度使用 Codex 的人來說，左側邊欄不是普通聊天記錄。
它更像項目的時間線。
一個功能為什麼這麼改，一個 bug 當時怎麼排查，一個工具怎麼搭起來，很多判斷都藏在這些舊會話裏。
所以我第一反應不是寫代碼。
我先想確認一件事：這些記錄到底是丟了，還是隻是看不見？
後來查下來，答案是後者。
記錄還在，只是當前 provider 看不到舊 provider 的索引。
於是我們順手把這個問題做成了一個開源工具。
項目地址是 https://github.com/Standed/codex-history-share
安裝後先跑這兩行。
因為它不是為了炫技出現的，它是從一個真實卡點裏做出來的。
一開始，我以為只是賬號問題
當時我用了一個 provider 切換工具，把 Codex 從 ChatGPT 登錄切到了 API 模式。
切完以後，右下角模型正常，提問正常，API 也正常。
但左側邊欄突然變得很空。
這時候最容易誤判，以為是賬號切換導致雲端歷史沒同步，或者 Codex 把舊記錄清了。
但本地一查，文件其實還在。
Codex 的歷史主要在下面幾個位置。
· ~/.codex/sessions
· ~/.codex/archived_sessions
· ~/.codex/state_5.sqlite
· ~/.codex/session_index.jsonl
真正的問題在 provider metadata。
你以前用的是 openai ，現在切到了 OpenAI 、 crs ，或者某個中轉 API。
歷史會話還在本地，但它帶着舊 provider 的標記。
Codex 當前只讀當前 provider 下的索引，於是舊會話就像站在另一扇門後面。
它不是沒了，它只是被當前視角擋住了。
這個發現挺有意思。
很多 AI 工具的問題，最後不是模型能力問題，而是狀態管理問題。
賬號、provider、token、會話、索引、加密內容、項目路徑。
每個東西單獨看都合理，但它們組合在一起，就會在某個凌晨把你的側邊欄變成空白。
我們沒有重寫輪子
這裏要感謝已有項目 https://github.com/Dailin521/codex-provider-sync 它已經把底層最麻煩的事情處理了，包括掃描 rollout 文件、更新 SQLite、修復項目可見性、創建備份和支持恢復。
所以我們沒有從零寫一遍。
做工具有時候最重要的不是證明自己什麼都會寫，而是判斷哪裏該複用，哪裏該補體驗。
底層同步已經有人做得很好，那我們就把它產品化一點。
於是有了 codex-history-share 。
第一版沒有做得很複雜，我只想先把最痛的地方補上。
你可以先用 codex-history status 看一眼，確認歷史到底分佈在哪些 provider 下面。
看清楚以後，再用 codex-history sync 把舊歷史同步到當前 provider。
如果你經常切 API、切賬號，手動同步就不夠了，所以它又補了 watch 和 install-agent 。
前者盯着本地配置變化，後者在 macOS 後台常駐，儘量讓這件事以後不要再打斷你。
最後還有一個 export 。
它不會讓舊會話跨賬號無損續聊，但至少能把標題、項目路徑、首條用戶消息這些索引導出來，給自己的工作記憶留一份保險。
我自己最在意的其實是 watch 和 install-agent 。
手動修一次當然可以，但如果一個工具每次切賬號都要你想起來手動修，它就還沒有真正融進工作流。
好的小工具應該像一個安靜的墊片。
你不需要一直想起它，但它在那裏，把兩個容易錯位的地方墊平。
有個邊界必須說清楚
這個工具不能做魔法。
它可以讓歷史會話重新顯示在左側邊欄，但不能把舊會話裏的 encrypted_content 重新加密到另一個賬號或 provider。
所以有些舊會話可以看見，但繼續對話時，仍然可能遇到 invalid_encrypted_content 。
這不是工具偷懶，這是加密內容和賬號、provider 綁定後的邊界。
現在很多 AI 工具在宣傳時，總喜歡把能做到和穩定做到混在一起。
但真正做給人長期用的工具，邊界比口號重要。
所以這個項目的定位不是跨賬號無損續聊神器。
更準確地說，它解決的是本地歷史可見性：讓 Codex 本地歷史在多 provider、多登錄方式之間儘量保持側邊欄可見，並提供備份、恢復和導出。
這句話聽起來沒那麼性感。
但它是真的能解決一個痛點。
一個小工具背後的判斷
這件事做完以後，我有一個很強的感受。
以後 AI Agent 的生態裏，會出現越來越多這種小工具。
它們不一定宏大，也不一定有華麗界面，甚至第一版可能只有幾條命令。
但它們會解決一些非常具體的摩擦。
比如切賬號後歷史看不見，本地狀態不同步，多工具之間上下文斷掉。
再往深一點，是某個配置一改，整個工作流突然失憶；一個 Agent 做完了事，另一個 Agent 接不上。
這些問題看起來都很小。
但真正每天用 AI 工作的人知道，小摩擦積累起來，就是生產力的漏水點。
你不是被一個大問題拖慢的。
你是被十幾個小斷點一點點打斷的。
而 Agent 時代真正值錢的工具，很多時候不是幫你生成一個很酷的東西，而是讓你的工作流少斷一次。
少斷一次，就多一口氣。
如果你也遇到這個問題
你可以直接試這幾行。
如果你用 macOS，並且經常切換 API 或賬號，可以裝後台監聽。
目前第一版更偏 CLI。
Skill 也一起放進倉庫了，後面可以讓 Agent 自動按這個流程幫用戶診斷和修復。
EXE、DMG、GUI 這些不是不能做，但我想先讓最核心的東西跑穩。
工具這件事，我現在越來越不迷信第一版就完整。
很多時候，第一版只要真實、可用、邊界清楚，就已經很好了。
寫在最後
這次最打動我的，其實不是寫了多少代碼。
而是這個過程很像未來我們和 AI 一起工作的樣子。
一個人遇到問題，說出來。
AI 去查本地狀態，讀開源項目，確認邊界，封裝 CLI，寫文檔，跑測試，推 GitHub，發 Release。
中間沒有宏大的發佈會，也沒有什麼顛覆行業的大詞。
就是一個小問題，被認真對待，然後變成了一個別人也能用的工具。
我覺得這就是智能體工坊最該做的事。不是每天追着大模型參數跑。而是把那些真實工作裏卡人的地方，一個一個磨平。
技術最後會不會改變世界，我不知道。
但它至少可以先把我們自己的工作台，擦得亮一點。
覺得有用的話，可以把這個工具轉給正在折騰 Codex 的朋友。
很多人不是不會用 AI，只是被這些小卡點攔住了。