Claude-Mem 云同步不上傳怎么排查hub.reachable 為 false 與 pending 積壓定位【免費(fèi)下載鏈接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem你剛在 Claude-Mem 里配好了云同步但記憶數(shù)據(jù)一直停在本地worker 在運(yùn)行、沒有報(bào)錯(cuò)數(shù)據(jù)庫里的 observation 卻沒有出現(xiàn)在 cmem.ai 的同步日志里。這篇針對的是「云同步不上傳」這一種故障通過 worker 暴露的GET /api/sync/status端點(diǎn)判斷到底是「連接沒有建立」hub.reachable為false還是「連接正常但本地隊(duì)列排不出去」pending計(jì)數(shù)持續(xù)積壓。適用前提已安裝 Claude-Mem 且 worker 在本地運(yùn)行云同步三要素sync token、user id、SyncHub URL至少部分已寫入~/.claude-mem/settings.json。以下排查依據(jù)來自 Cloud Sync 文檔、CMEM Pro 手動(dòng)/無頭配置文檔 和 cloud-sync skill。先確認(rèn)同步是否處于「已配置」?fàn)顟B(tài)云同步?jīng)]有單獨(dú)的開關(guān)只有當(dāng)CLAUDE_MEM_CLOUD_SYNC_TOKEN、CLAUDE_MEM_CLOUD_SYNC_USER_ID、CLAUDE_MEM_CLOUD_SYNC_HUB_URL三個(gè)值都非空時(shí)同步才激活任意一個(gè)留空即視為關(guān)閉。所以第一步不是查網(wǎng)絡(luò)而是查 worker 自己認(rèn)為的配置狀態(tài)。狀態(tài)端點(diǎn)無條件注冊——未配置的機(jī)器也返回200和{configured: false}而不是404這樣調(diào)用方可以區(qū)分「沒配」和「worker 掛了」兩種情況見 CloudSyncRoutes.ts。查詢 /api/sync/status 并解讀字段先解析 worker 端口取自環(huán)境變量CLAUDE_MEM_WORKER_PORT否則從~/.claude-mem/settings.json讀取都取不到時(shí)用 UID 推導(dǎo)的回退端口再請求狀態(tài)端點(diǎn)PORT${CLAUDE_MEM_WORKER_PORT:-$(node -e const fsrequire(fs),prequire(path),osrequire(os);const uid(typeof process.getuidfunction?process.getuid():77);const fallbackString(37700(uid%100));try{const sJSON.parse(fs.readFileSync(p.join(os.homedir(),.claude-mem,settings.json),utf-8));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);} 2/dev/null)} curl -s http://127.0.0.1:${PORT}/api/sync/status配置完成時(shí)的響應(yīng)形如文檔示例字段值不是固定預(yù)期{ configured: true, deviceId: 2f6b1c9e-7d41-4c1a-9b0e-3d5f8a2c6e10, pending: { observations: 0, summaries: 0, prompts: 2, mutations: 0, tombstones: 0 }, quarantine: { count: 0, latestReason: null }, lastFlushAt: 1783981042731, lastError: null, hub: { checkedAt: 1783981042800, reachable: true, epoch: 1783981042000, headSeq: 42, projectedSeq: 42, error: null } }關(guān)鍵字段的判斷含義字段含義pending尚未上傳的行以及排隊(duì)的 mutation 操作數(shù)量。接近 0 表示 Hub 日志已包含本機(jī)寫下的全部內(nèi)容lastFlushAt最近一次成功 flush 的 epoch 毫秒時(shí)間戳從未成功過則為nulllastError最近一次失敗 flush 的錯(cuò)誤信息健康時(shí)為null且不會包含 tokenhub.reachable最近一次對 SyncHub 的認(rèn)證探測結(jié)果把它當(dāng)作連接性檢查的標(biāo)準(zhǔn)hub.error探測失敗時(shí)的具體原因token 被脫敏為[REDACTED]hub.epoch/hub.headSeq/hub.projectedSeq恒為十進(jìn)制字符串未配置時(shí)響應(yīng)只有{ configured: false }。hub.reachable 為 false連接未驗(yàn)證文檔明確給出判斷規(guī)則hub.reachable: true才算連通只有l(wèi)astError: null并不夠——因?yàn)榭贞?duì)列不會觸發(fā)任何 push單看lastError為null會把「什么都沒上傳」誤判為「連接正?！?。這也是為什么每次configured: true的狀態(tài)請求都會附帶一次對 SyncHub 的認(rèn)證、只讀GET /v1/sync/status探測即使所有 pending 計(jì)數(shù)為零。該探測不追加操作、不推進(jìn) pull 游標(biāo)。hub.reachable: false配合hub.error因此能暴露出空隊(duì)列本會隱藏的問題token 無效、Hub URL 寫錯(cuò)、響應(yīng)格式異常、超時(shí)或網(wǎng)絡(luò)故障。定位步驟讀hub.error字段先判斷錯(cuò)誤屬于哪一類。對照cmem.ai → Connect頁面核對三個(gè)值sync token、user id、SyncHub URL。注意 Hub URL 必須是絕對的https://地址且不能填成 cmem.ai 的應(yīng)用 API 地址——客戶端只與 SyncHub 通信。確認(rèn)~/.claude-mem/settings.json中三個(gè)鍵寫的是CLAUDE_MEM_CLOUD_SYNC_TOKEN/CLAUDE_MEM_CLOUD_SYNC_USER_ID/CLAUDE_MEM_CLOUD_SYNC_HUB_URL而不是寫錯(cuò)鍵名。改完配置后重啟 worker 再驗(yàn)證。skill 中給出的重啟方式是直接調(diào) worker 的管理端點(diǎn)curl -s -X POST http://127.0.0.1:${PORT}/api/admin/restartnpx claude-mem restart是等效的替代路徑見手動(dòng)配置文檔。重啟是為了讓 worker 不再持有舊的內(nèi)存中 provider/sync 狀態(tài)。重啟后立即出現(xiàn)連接拒絕、404或503是正常的worker 還在拉起。按文檔建議每 3 秒重試一次、持續(xù)約 30 秒再判定為 worker 本身故障。驗(yàn)證成功的三個(gè)條件是同時(shí)滿足configured: true、hub.reachable: true、lastError: null。hub.reachable 為 true 但 pending 不下降積壓定位連通正常卻仍積壓時(shí)先理解 pending 的機(jī)制數(shù)據(jù)庫本身就是隊(duì)列——每張同步表都有synced_at列NULL表示該行進(jìn)過 Hub 日志。每次寫入后worker 觸發(fā)一個(gè)去抖 flusher 排空WHERE synced_at IS NULL的行失敗上傳會讓行保持NULL由下一次寫入加上帶上限的指數(shù)退避30 秒 → 10 分鐘重試寫路徑本身永不被阻塞。因此少量 pending 會自行排空需要盯的是它長期不降。逐項(xiàng)核對lastError非null時(shí)它就是最近一次 flush 失敗的原因直接按錯(cuò)誤內(nèi)容處理。lastFlushAt若為null說明從未成功 flush 過配合hub.reachable: true看lastError就能區(qū)分「網(wǎng)絡(luò)通但上傳被拒」和「還沒輪到 flush」。pending的口徑計(jì)數(shù)只描述 SyncHub 上線基線之后本機(jī)產(chǎn)生的寫入安裝前已有的本地記憶庫不算遷移語料也不會體現(xiàn)在 pending 里。如果你的期待是「老數(shù)據(jù)應(yīng)該先全量上傳」這個(gè)期待與文檔不符——pending 長期為 0 或很小是正常的。quarantine.count大于 0 表示有行被隔離latestReason給出最近一條原因可作為積壓中「重試也不了」部分的線索。邊界與限制設(shè)備數(shù)上限Hub 每賬號最多接受 64 個(gè)不同 device id。達(dá)到上限后已有設(shè)備照常同步新設(shè)備會收到409 device_limit_exceeded。關(guān)閉同步把三要素中任意一個(gè)置空即可無需卸載。隱私云同步會把 observation 敘事全文和你的完整 prompt 文本上傳到 cmem.ai 賬號下的 SyncHub如果這些內(nèi)容必須留在本機(jī)不應(yīng)啟用。文檔示例中的deviceId、時(shí)間戳和headSeq數(shù)值僅作格式參考不是固定預(yù)期值。排障完成后日常巡檢可以直接在 Claude Code 里運(yùn)行/cloud-syncskill它會走同一套「查狀態(tài) → 必要時(shí)寫配置 → 重啟 → 驗(yàn)證」的路徑并在結(jié)束時(shí)提示上述隱私聲明?！久赓M(fèi)下載鏈接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考