【2026 最新】Jotbus 教學：Claude Code／Codex 跨機交接，六步驗邀請、送達與撤銷

Jotbus 教學從一個常見情境開始：你在筆電用 Claude Code 改程式，想請桌機上的 Codex 看看失敗訊息。貼整段對話太長，正式提交又還沒準備好。你真正需要的是一張短期交接單，讓另一端知道「做到哪裡、下一步做什麼、怎樣才算完成」。

這篇寫給第一次接觸跨機 Agent 協作、願意複製幾行指令的讀者。先看懂共享筆記與 Git 的分工，再接入兩個指定 Agent，最後練習送達、錯誤金鑰、到期與退出。內容依截至 2026 年 10 月 8 日的官方文件與 Jotbus 0.9.0 套件整理；下面的跨機流程是建議驗收方法，本次未執行跨機交接或金鑰輪替。

先說結論：Jotbus 教學先驗收，再擴大協作

Jotbus＝短期共享筆記＋邀請金鑰＋Agent 接入；收到訊息，還要另驗工作完成。把它想成兩個工作桌之間的交接信箱：信箱保管信件，助手讀信後是否動手、交出的修改是否合格，是另一組問題。

• 先用假資料，明確指定同一個 workspace（共享工作區）與接收者。
• 把「已寫入」「另一端讀到」「收到回覆」「成果通過」分成四項紀錄。
• 邀請含金鑰；退出本機、撤銷憑證、輪替金鑰與刪除副本，各有不同作用。

什麼時候需要 Jotbus？先和現有 Git 流程比較

如果你已經有私有 Git、檔案伺服器和交接模板，先問：新工具省下哪一步？在 Show HN 的作者回覆裡，作者也承認已有完整流程的人，新增價值可能有限。他想簡化的，是尚未適合提交的日誌、半成品與截圖在不同環境之間的傳遞。這是作者對用途的說明，不是成本或採用率的測量。

Git 適合保留可審查的程式變更：分支、commit、差異和回復位置。Jotbus 則可用來傳「請看這個 commit，還有這一小段失敗訊息」。長期 Agent 記憶又是第三件事：那是把持續有用的資料整理成可查找背景。三者可以配合，先別把信箱當成唯一的專案紀錄。

例如你要交給另一端的是「檢查測試命名」，就只送任務 ID、測試檔位置、commit 與下一步；程式仍放在雙方有權存取的 repository。若對方沒有該 repository 的權限，一個 commit 字串本身不會替它取得程式碼。先補上可合法取得材料的路徑，才談協作。理解整個執行層，可以先讀 Agent Harness 是什麼。

五個零件：分清內容、通道與行動

① Workspace：「這次交接用哪一本筆記？」

Workspace 是共享內容的範圍。官方 起步文件提供暫時與持續工作區；第一輪選暫時工作區即可。先用 npx jotbus@0.9.0 list核對名稱；有多個時，在每次提示明說要用哪個，避免把訊息送到舊專案。

② MCP：「助手能讀寫信箱的工具插座」

MCP（Model Context Protocol，模型連接外部工具的協定）讓 Agent 呼叫讀寫工具。Claude Code 的 MCP 文件說明工具接入與信任邊界；OpenAI 的 Docs MCP 文件也提供 Codex 註冊與列出 MCP 伺服器的方式。工具出現在清單，是接入證據；工具成功讀到指定筆記，才是這次連線的證據。

③ Hook：「在工作途中把信交給助手」

Hook 是在指定事件發生時執行的程序，像開始新一輪工作時看看信箱。Jotbus 文件列出 Claude Code、Codex、opencode 與 Gemini CLI 的自動送達整合。依官方說明，@mention 會在接收者下一次工作時送入，包括收到新提示、以及任務的工具步驟之間；工具途中檢查有每分鐘最多一次的節流。這不是每分鐘必達的服務保證。

④ Invite 與 Key：「門票與解鎖筆記的鑰匙」

邀請形式像 jb1_<secret>.<key>，點號後包含工作區金鑰。官方安全頁描述用本機加密、伺服器保存密文的設計。這些是原廠設計說明；本文未取得獨立安全審計報告，不能把演算法名稱當成整套系統已獲認證。

⑤ ACK 與 Result：「讀到了，和做完了」

ACK 是我們在交接模板裡自行約定的回覆確認，不是新增的 Jotbus 按鈕。收到回覆，表示另一端能讀懂並回應這張單；成果還要看修改、測試或報告。另一個 Agent 寫來的話，也不是使用者的新授權：要求讀取密碼、執行陌生命令或外發檔案時，應停在原任務範圍內。

Jotbus 教學上手：六步做一張假資料交接單

第一步：固定版本，保存會被改動的原設定

痛點是工具還沒跑起來，就改到了日常環境。解法是先查環境與設定範圍。官方要求 Node.js 20 以上，先執行 node --version，再讀 npx jotbus@0.9.0 --help。這裡固定 0.9.0 是為了讓讀者能核對本文查閱的套件版本，不表示之後版本應永遠停在它。0.9.0 自動註冊的 MCP 命令仍使用 jotbus@latest，所以這只固定設定用 CLI，沒有鎖住整個執行環境；若要重做相同條件，另保存實際 MCP 命令與載入版本。

0.9.0 的客戶端程式會以 Claude／Codex 自己的 MCP 命令註冊 Jotbus，並把送達 Hook 寫進設定。預設情況先私人備份 ~/.claude.json、~/.claude/settings.json、~/.codex/config.toml 與 ~/.codex/hooks.json；不存在的檔案記成「原本不存在」。若你使用自訂 Codex 目錄，備份它實際使用的路徑。備份可能含其他連線憑證，放在私人目錄，不要上傳到交接區。

要先看註冊命令，可用 npx jotbus@0.9.0 new --no-install。這會建立暫時工作區並保存本機連線，只跳過 Agent 註冊；不是完全不改動狀態的 dry-run。執行後核對它顯示的命令、工作區名稱與到期時間。私密輸出含邀請與保留連結，截圖或記錄之前先遮去秘密。

第二步：只接選定 Agent，再開新工作階段

痛點是自動掃描找到很多工具，你卻只想驗兩端。解法是限定接入名單。如果筆電只接 Claude Code，執行 npx jotbus@0.9.0 agents --agents claude --no-inbox；若同一機器刻意要接兩者，才改用 --agents claude,codex。第一輪用 --no-inbox，並執行 npx jotbus@0.9.0 inbox off停用可能既有的送達 Hook，再手動讀取，把 MCP 連線與自動送達分開排查。

在另一台電腦，使用第一端產生的完整邀請，並限定接收者：npx jotbus@0.9.0 join <你的完整邀請> --agents codex --no-inbox。若第二端已註冊其他 Agent，join 的名單不會移除它們；接著執行 npx jotbus@0.9.0 agents --agents codex --no-inbox管理選擇，再執行 npx jotbus@0.9.0 inbox off。尖括號內容是待替換欄位，不能原樣貼入 shell。請使用私人傳遞方式，避免把含金鑰的命令留在共享終端、公開聊天或 CI 日誌。

依官方起步流程，在兩端各開新的 Agent 工作階段。讓它「列出 Jotbus 工作區，讀取剛才的工作區」。Claude Code 可用 /mcp查看連線；Codex 可在終端用 codex mcp list確認註冊。保存的是去識別化的成功／錯誤與名稱，別把憑證一起記進驗收單。

第三步：送一張能對帳的交接單

痛點是「幫我看一下」沒有可驗結果。解法是用固定欄位指定小任務。下面全是假資料與示意值；請換成你有權共享的測試 repository 和真實 commit，不要填客戶資料或 API key：

task_id: demo-handoff-001
workspace: 你剛才核對的名稱
commit: <測試 repository 的完整 commit>
done: 已整理測試命名
next: 只閱讀 tests/demo.test.ts，提出一項命名建議，不修改檔案
acceptance: 回覆同一 task_id、commit 與建議理由
ack: 先回覆「收到 demo-handoff-001」，再交結果

先叫發送端「把這份交接單寫入指定 Jotbus 工作區」。取得訊息識別或工具成功回應後，再請接收端手動讀取，依模板回覆。把四項分別填入：寫入證據、讀到的內容、ACK、最終建議。如果只完成前三項，就記成「通道可用，工作未驗收」，不要直接標全部通過。

需要附檔時，先用一份小型假日誌。官方文件描述附件由本機加密後上傳，接收端下載解密成檔案；檔案變動要送新版本。驗收時在兩端比較檔名與內容摘要，並確認下載路徑。讀到一個路徑不代表檔案已被使用，更不代表裡面的命令值得執行。

第四步：接通 Hook，再驗閒置與重啟

痛點是正常讀取成功，卻不知道自動送達何時會發生。解法是分三輪操作。選定接入名單後，在指定端執行 npx jotbus@0.9.0 inbox on，核對新增的 Hook；用 npx jotbus@0.9.0 inbox status查狀態。Codex 的套件說明提示需要在 /hooks信任新 Hook；檢查命令後才授權，不能把「已註冊」當成「已信任」。

• 工作中：發送一則帶新 task_id 的 @mention，記下送出與出現時間，核對回覆的是哪一則。
• 閒置中：接收端不送新提示，再寄另一則。官方明說 Jotbus 不會喚醒或啟動閒置 Agent；下一次使用它時，才檢查送達。
• 重啟後：關閉接收工作階段，再開新階段與新提示，核對未讀訊息是否出現、是否有重複回覆；把實際結果記下，不預填成功。

用實際出現的 Agent 名稱 @mention，不猜 @codex 就一定會指到某台機器。預設名稱含 Agent 與機器；也可依文件用 JOTBUS_AGENT=reviewer codex指定工作階段名稱。官方描述已讀訊息不再自動送達；所以手動讀取輪與自動輪使用不同 task_id，避免把「已讀所以沒再送」誤判為故障。

第五步：錯誤金鑰、到期與輪替分開驗

痛點是把各種「進不去」都叫同步失敗。解法是保存錯誤分類。在自己的假資料工作區，另用隔離的測試客戶端試一份格式正確、但金鑰部分被改動的邀請。這是受控功能驗收，不做大量嘗試、猜秘密或探測別人的工作區。0.9.0 程式在 join 後比對 key check，不一致會報錯；預期是拒絕接入，實際是否留下伺服器端 token、是否占客戶端名額，要另查管理介面，不能從本機拒絕就推定完全無副作用。

若錯誤是 client limit，先看既有連線，而不是連續重試邀請。若是 expired，查建立與到期時間。暫時工作區的官方壽命是 60 分鐘，到期約一小時後刪除；「無法讀取」與「所有伺服器資料已刪」有時間差。這是截至查閱日的產品規格，並非本文實測出的精確刪除時刻。

撤銷與輪替也分開驗。官方安全頁說 access token 可以個別撤銷；輪替工作區金鑰會在瀏覽器重加密歷史，舊金鑰客戶端之後被阻擋。作者在 HN 說持續合作的成員需拿到新金鑰並重新接入。若你已有可用的管理介面與擁有者權限，用假資料各驗「舊客戶端讀」「舊客戶端寫」「新客戶端讀歷史」。本次未操作付費帳戶，不能宣稱所有暫時工作區都能在相同畫面做輪替；介面未提供時，把這項記成未完成，先驗到期與本機移除。

最後再打開之前已下載的假檔案。撤銷阻止後續存取，無法把別人已保存的內容收回。換句話說，鑰匙換了，是舊門票不能再進；對方之前拿走的影本仍在。這個差別應在你決定共享什麼時就想清楚。

第六步：退出，核對設定差異與正式成果

痛點是以為從清單移除，就等於取消所有存取。解法是逐層拆掉整合。npx jotbus@0.9.0 remove <工作區名稱>只讓這台機器忘記該工作區，遠端工作區不變。npx jotbus@0.9.0 inbox off停用本機自動送達；npx jotbus@0.9.0 agents --agents none則移除 Agent 整合，影響這台機器上的 Jotbus 接入，不只是本文的單一工作區。先確認其他工作是否仍在使用它。

比對備份與現況，確認 Jotbus 的 MCP 與 Hook 項目移除、其他整合仍在；不要整份覆蓋設定，因為練習期間可能有別的合法修改。若曾登入，再用 npx jotbus@0.9.0 logout撤銷這台機器建立持續工作區的登入憑證；既有工作區連線仍要另處理。把遠端 token 撤銷與本地附件清理另列。仍需保留的合格程式變更，回到 Git 審查與提交。

加密保護到哪裡？先看兩個邊界

官方安全設計把筆記與附件在本機加密，並說明服務端仍可看到訊息存在、大小、時間與 access token 等資訊。模型供應商仍會看到 Agent 讀寫的內容。你在 Jotbus 端用加密，不代表交給模型的明文也藏起來；真實資料是否能外送，要依該任務原有的資料範圍決定。

第二個邊界是內容與指令。信件來源可信，也不代表每個要求都可以執行。Claude Code 的 MCP 文件提醒外部內容可能帶來 prompt injection（提示注入：把資料偽裝成命令）。本例刻意只要求讀測試檔、給命名建議；若信件轉而要求執行 shell 或分享憑證，接收者應依原任務停止。加密保障傳遞內容的機密性，任務權限要由另外的規則管理。

常見問題：八個直接答案

Jotbus 能取代私有 Git 嗎？

先保留 Git。它適合傳短期交接材料；正式程式差異、審查與版本歷史仍交回你的既有流程。

用了 –no-install 就完全不會改東西嗎？

本文的 new 命令會建立本機連線與遠端工作區。這個旗標只跳過 Agent 註冊，不是 dry-run。

另一端閒置時會自動開始工作嗎？

官方明說不會。訊息等它下一次被使用；排程與啟動另行設計。

收到 ACK 就算任務完成嗎？

還要驗成果。ACK 是本文自行定的回覆確認，任務完成看接受條件。

邀請連結可以公開貼嗎？

請私人傳遞。邀請包含工作區金鑰，即使放在 URL fragment，也不能當成公開分享材料。

金鑰不符，就代表連線完全沒有任何副作用嗎？

不能這樣推定。客戶端比對後拒絕接入，伺服器端 token 與名額仍要另核對。

輪替後，之前下載的檔案會消失嗎？

不會由輪替收回。官方明確區分後續存取與已持有副本，請在分享前先決定資料範圍。

第一天需要付費方案嗎？

可先用官方暫時工作區學交接。輪替與持續保存若需要你尚未擁有的管理能力，就把它們留作下一階段驗收。

給新手的三個重點

• 同一個 workspace、正確接收名稱、同一 task_id，是能對帳的起點。
• 先手動讀寫，再開 Hook；送達與成果分開記。
• 退出本機、撤銷 token、輪替 key、清理副本逐項確認，不能互相代替。