GitHub Repo
Hermes Agentコミュニティ、圧縮後の履歴欠落とデスクトップ版での編集位置ずれの可能性を報告
11月1日のHermes Agentコミュニティからの報告によると、インプレース圧縮後に履歴APIがアーカイブ済みメッセージを返さない場合があり、デスクトップ表示と編集位置の不一致につながる可能性がある。報告者はテストと修正ブランチを公開したが、確認時点でメンテナーによる確認や正式なマージは確認されていない。

Hermes Agentコミュニティは11月1日、長い会話で一貫性が損なわれる問題を報告した。インプレース圧縮の実行後、session.historyが、以前は表示されていて現在はアーカイブ済みの応答や音声メッセージを返さない場合がある。同じ会話でも別の読み取り経路からはそれらの内容を確認できるため、クライアントによって取得する履歴が一致しない。報告は当日のメインブランチを対象とし、再現テストと公開済みの修正ブランチが添付されているが、正式に修正された機能とみなすことはできない。issueと再現手順
公式ドキュメントによると、Hermesはメッセージ全体やツール呼び出しなどのデータをSQLiteに保存する。圧縮はモデルが現在使用するコンテキストを短縮するためのもので、記録の削除を意味しない。また、表示用のエクスポートにはインプレース圧縮でアーカイブされたターンを含めるべきであり、完全バックアップにはロールバックや編集によって削除されたデータも保持されると説明されている。こうした設計では、「モデルが現在読み取るメッセージ」と「ユーザーに表示すべき履歴」は別々のデータビューとなる。公式セッションドキュメント
報告者の分析では、問題の原因は、履歴APIが有効な会話コンテキストのみを読み取る一方、デスクトップ表示にはアーカイブ済みのターンも含まれる点にある。ユーザーがタスクを中断した後、過去のメッセージを編集しようとして、その文面が最新のプロンプトと同じ場合、位置特定処理が比較するインデックスがずれる可能性がある。報告者のプローブケースでは、以前のcontinueが最新のものとして解決された。また、メッセージ数と実際に返されたリストが一致しないケースもあった。これらは現時点では報告者によるテスト結果であり、独立した再現確認は得られていない。技術分析
提案されている修正方針は、表示用履歴と有効なメッセージを統合し、アーカイブ行にマーカーを付け、編集位置の特定とカウント処理も合わせて調整することだ。エージェントシステムのエンジニアにとって注目すべき点は、圧縮後のデータ契約である。画面表示、履歴API、編集操作で一貫したメッセージ識別情報を共有すれば、同じ文面のプロンプトによる曖昧さを避けられる。今後は修正のマージに加え、アーカイブ、ロールバック、重複プロンプトに関する回帰テストを確認する必要がある。現時点の証拠から、基盤データが削除されたと推論することはできない。