排程任務與自動執行相關的官方 issue。 資料來自官方 GitHub repo，狀態由官方 label 推導，每筆附原始連結與最後檢查日期。
使用者同時執行多個 Hermes profile，但發現非 default profile 在多個子系統中被當成次等公民對待，例如 cron job 會寫到錯誤 profile 的目錄、dashboard 功能只看得到 default profile、Desktop App 完全忽略非 default 的 session。issue 把這些個別問題彙整成一個總覽，指出根因是程式碼假設 ~/.hermes/（default 根目錄）才是唯一正式路徑。
與 #58258 相同的 bug：cron job 透過 deliver: origin 送訊息到 Telegram 時，打字中提示會持續顯示到整個子程序結束，而非訊息送達後就消失，長時間背景工作會讓提示持續 30 到 60 分鐘以上。此 issue 已標記為重複並關閉。
當 cron job 透過 deliver: origin 送訊息到 Telegram 時，打字中提示會持續顯示到整個 cron job 子程序結束為止，而不是訊息送達後就消失。若 cron job 送出簡短通知後還繼續跑背景工作，使用者的 DM 就會持續顯示打字中長達 30 到 60 分鐘以上。
## 现象 在 Yuanbao 平台创建 cronjob 时用 `deliver=origin`，投递时好时坏。看日志基本就是两种结果： 1. 正常投递（live adapter 路径命中） 2.
回報者指出目前 hermes kanban ls 只能顯示靜態結果，需要手動重新執行才能看到進度，也沒有明顯區分「閒置」與「執行中」任務的視覺提示。提案新增 CLI 的自動刷新模式、TUI 看板中執行中任務的閃爍提示、狀態變化的 Telegram 通知，以及顯示 worker 的最後心跳時間。
此 issue 回報 cron/scheduler.py 會將 os.environ["HERMES_CRON_SESSION"] 設為行程層級的全域變數。由於 cron 工作是在長駐的 gateway 行程中執行，此變數一旦被第一個 cron job 設定，就會持續影響到後續所有互動式 session（例如使用者正在使用的 Telegram 對話），使其被核准層誤判為 cron session。在預設的 approvals.cron_mode: deny 下，會導致 execute_code 在真人使用者在場的對話中被永久封鎖。
錯誤訊息中提及可將 approvals.cron_mode 設為 approve 以避免 execute_code 被封鎖，但這只是繞過核准機制的權宜設定，非根本修復。
回報者在 Windows 環境下用 hermes cron create 搭配 --no-agent --script 建立純腳本排程任務時，程式在驗證排程前就因型別錯誤而失敗，回報者認為這是 cron job 建立流程中的 schema 或 runtime 型別問題，而非使用者輸入錯誤。
在 macOS 桌面版切到自建 profile（例如只設定 WeChat 的 rucy）時，UI 仍會顯示屬於 default profile 的 sessions、通訊頻道與 cron jobs，屬於 UI 層的跨 profile 資料外洩。
自從某次修正（#22773）後，cron 排程投遞到 Telegram 私訊（DM）forum 主題的訊息會被導向 General/主要主題，而非目標主題，即使 cron 設定的投遞目標本身是正確的；根因是 cron/scheduler.py 對「私訊主題」的分類判斷邏輯有誤。此 issue 已關閉。
當 cron 排程訊息指定投遞到 Telegram 私訊（DM）的特定主題時，由於路徑中只帶有一般的 thread_id、缺少私訊主題所需的中繼資料，Telegram adapter 可能拒絕或改成投遞到主題之外，導致訊息沒有出現在原本指定的主題中。
回報者指出使用 OAuth 型 provider（如 openai-codex）的 cron 排程工作，在憑證池耗盡時會直接以 HTTP 429 錯誤失敗，而不會像一般 gateway/CLI 主對話那樣自動切換到設定好的 fallback_providers 備援鏈，因為 cron/scheduler.py 走的是不同的程式路徑。
目前 Kanban 看板與 Desktop app 是分開的，使用者要另開終端機下指令（如 hermes kanban list）並手動複製任務 ID，造成多 agent 協作時的操作阻力。此 issue 提議在 Desktop app 加入側邊欄或 /kanban 指令，讓使用者不用離開聊天介面就能查看與操作看板任務。
回報者指出 cron 排程工作中 memory 工具雖然出現在可用工具清單，但實際呼叫時會失敗並顯示「Memory is not available」。原因是 cron 排程用 skip_memory=True 建立 AIAgent，但預設工具集仍繼承包含 memory 的核心工具，導致工具存在但無法使用。
此 RFC 追蹤已實作的看板功能 PR #16100，內容包含將原本以 cron 驅動改為長駐 daemon（hermes kanban daemon）搭配 systemd、拖放式看板 dashboard 外掛、執行歷史與 worker log 面板、即時 WebSocket 更新，並經過四輪稽核與外部審查，測試涵蓋多行程併發、真實子行程端到端測試與大量隨機化操作的性質測試。此 issue 已關閉，狀態為已修復，後續留言討論轉往 PR #16100 進行。
Hermes 的 cron 排程工作會在獨立的 session 中執行，執行結果送到 origin/home channel 時只有人類看得到，並附註「agent 無法看到這則訊息」，不會被寫進主要 gateway session 的對話紀錄，導致主 agent 常常不記得自己執行過排程任務，使用者得主動詢問才知道任務有沒有完成。
目前只能靠檔案系統交接（cron 把結果寫進共享的 .md 檔案），再由使用者手動要求主 agent 去讀這個檔案。