read-codex-history

Codex の履歴を読む

Codex の証拠のみを読み取ってください。以前のタスクを続行したり、そのプロジェクトを変更したりしないでください。読み取り完了後にユーザーが実行を希望する場合は、確認済みの証拠を daymade-claude-code:continue-codex-work に渡してください。

Codex の履歴を確認できる場所

場所	信頼性	用途
<codex-home>/history.jsonl	ユーザーが送信した内容。セッション ID と内部エポックタイムスタンプでキー付けされています	直近のユーザー入力を正確に一覧表示
state_*.sqlite	cwd、タイトル、更新時刻、ロールアウトパスなどのインベントリメタデータ	すばやい一覧表示と候補の検出
sessions/**/rollout-*.jsonl および archived_sessions/**	ユーザー／アシスタント／ツール／圧縮／フォークの全イベントストリーム	インデックスまたは物理的な事前選別の後に行う、正確なセッションの証拠確認とキーワード検証
<codex-home>/logs_*.sqlite（mtime が最も新しいものを選択）	実行時イベント：イベントごとの ts、level、target、feedback_log_body、process_uuid（OS の PID を含む）、任意の thread_id	どの稼働中プロセスで、どのような障害が起きているか — エラー形状による分類と時間分布

ある場所の情報を別の場所の情報で代用しないでください。プロンプト台帳の行が証明するのは送信された内容であり、エージェントの回答ではありません。状態 DB のパスは、ロールアウトの session_meta.id が一致するまでは候補にすぎません。プロンプト台帳の行がなくてもロールアウトが存在する場合があり、子ロールアウトがなくても /fork プロンプトが存在する場合があります。実行時ログのスレッドは、state_*.sqlite で確認されるまでは再開可能なセッションではありません（下記参照）。

実行時エラーログ（logs_*.sqlite）

「Codex が遅い／何度も再接続する／どのセッションでエラーが起きているか」といった場合は、ネットワークやサービスのせいにする前に、このデータを確認してください。エラーの形状と発生時間帯で分類します。特定の時間帯にエラーが集中していれば一時的な通信の不安定さ、一定の頻度で発生していれば継続的な問題、他のプロセスに問題がない中で特定の process_uuid だけが失敗していれば、障害ではなくプロセス固有の原因（古いインメモリトークンなど）が考えられます。

-- error shapes in the last 24h
SELECT CASE WHEN feedback_log_body LIKE '%timed out%' THEN 'timeout'
            WHEN feedback_log_body LIKE '%could not be refreshed%' THEN 'token-refresh'
            WHEN feedback_log_body LIKE '%error sending request%' THEN 'send-failure'
            ELSE 'other' END AS shape, COUNT(*)
FROM logs WHERE ts >= strftime('%s','now','-24 hours') AND level IN ('ERROR','WARN')
GROUP BY shape ORDER BY 2 DESC;

-- the same buckets per hour: clustered windows or a steady rate?
SELECT strftime('%m-%d %H', ts, 'unixepoch', 'localtime') AS hr,
       SUM(feedback_log_body LIKE '%timed out%') AS timeouts,
       SUM(feedback_log_body LIKE '%could not be refreshed%') AS token_refresh
FROM logs WHERE ts >= strftime('%s','now','-72 hours') AND level IN ('ERROR','WARN')
GROUP BY hr ORDER BY hr;

-- which OS processes are failing, and since when
SELECT process_uuid, COUNT(*), datetime(MIN(ts),'unixepoch','localtime') first_seen
FROM logs WHERE feedback_log_body LIKE '%could not be refreshed%'
GROUP BY process_uuid ORDER BY 2 DESC;

2026-10-03 に確認された注意点：

• ここで見つかる thread_id は app-server のスレッドハンドルであり、再開可能なロールアウトの存在を証明するものではありません。codex resume <id> を案内する前に、state_*.sqlite の threads.id にその ID が存在することを確認してください。ログにしか存在しない ID を指定すると、「No saved session found with ID」というエラーになります。
• strftime('%s', '<local wall time>', 'localtime') は二重変換を行うため、境界時刻が未来にずれて、データがないように見える 0 件の結果を返すことがあります。境界時刻には UTC のリテラル（ローカル時刻からオフセットを引いた値）を指定してください。

データソースの検出、タイムスタンプ、書き込みロックのセマンティクス、従来の Kimi との互換性、ストレージ障害については、references/storage_and_portability.md を参照してください。フォークのスナップショット、圧縮、イベントストリーム、終了理由を解釈する前に、references/codex_rollout_format.md を参照してください。

求める結果から選ぶ

ユーザーが求めていること	使用するもの
最近の Codex セッション、タイトル、ID、または書き込みロックが保持されていたことを示す確かな証拠	scripts/list_local_history.py --source codex --index-only。インデックスを利用できない場合、インベントリは不明のままです
貼り付けた引用を含むセッションを、プロジェクト、日付、タイトルの手がかりをもとに特定する	以下の引用されたやり取りを特定する：候補をインベントリし、元のメッセージを確認します
セッションごとにグループ化した、最新から古い順の正確な最近のユーザー入力	scripts/list_codex_user_inputs.py
継承した履歴を含む、会話全体の元入力数と引用	scripts/reconcile_codex_inputs.py --session <ID>
内部識別情報から特定のロールアウトを特定する	scripts/analyze_sessions.py locate-codex <ID>
1つのセッションと、宣言された親スナップショットを再構成する	scripts/read_codex_session.py --session <ID>
会話を収集せずに、エクスポーターが取得したロールアウトのプレフィックスを検証する	エクスポーター向けの取得済みロールアウト検証
既知のセッションですでに読み取られたツールの戻り値、コメント ID、外部メッセージを検証する	以下の元のツールと記録の証拠コマンド。ブリーフィングのプレビューは、ツールの証拠を網羅していません
トピックやフレーズを含むロールアウトを探す	read-claude-code-history/scripts/history_index.py recall --provider codexを実行し、正確なロールアウトを確認します
エラーが発生している稼働中のプロセス、時間経過に伴うエラーの形、再接続／タイムアウトの履歴	前述のランタイムエラーログセクション（logs_*.sqliteの分類）。ロールアウトイベントストリームではありません
内容は覚えているものの、表現が変わってしまったもの	ベクトルが完全な場合は、同じインデックス検索をハイブリッドモードで実行します
証拠が揃った後に続行する	読み取りを終了し、daymade-claude-code:continue-codex-workを呼び出します

求められている出力を、動機より優先してください。「最近の元入力を見せて」という依頼には、時系列の生入力テーブルで応えます。フィードバックの分類、トピックの抽出、インタラクティブアプリ、すべての過去セッションを示すものではありません。

「この会話で何件のメッセージ／フィードバックを送ったか。すべて原文のまま列挙して」という依頼では、references/user_input_reconciliation.mdを読みます。リコンサイラーを使って、既存の台帳と厳密な系譜リーダーを組み合わせてください。出現箇所、元の文字列、ソース座標が保持されます。終了コード2またはcomplete: falseは未完了の結果として扱ってください。scope_input_count: nullはゼロではなく、検証済みの入力も完全な合計ではありません。不一致の記録は、ハッシュに紐づく除外情報を指定する前に、実際のソースと照合してください。集計単位と締め切り時点を明示し、メッセージ数を異なる批判の数と呼ばないでください。通常の最近の入力に関する依頼では、台帳のみのルートを使用してください。

コマンド

スクリプトは、このSKILL.mdからの相対パスで解決してください。アドホックなSQLite、Node、jq、再帰的なgrepで結合処理を組み直さないでください。

最近のインベントリ

<skill-dir>/scripts/list_local_history.py \
  --source codex --index-only --cwd <workspace> --limit 20 --language zh

書き込みロックの出力は、肯定的な情報のみを示します。ロック保持中であれば、そのスナップショット中に該当するアドバイザリロックが保持されていたことを証明しますが、プロセスを特定したり、稼働中であることを証明したりするものではありません。マークのない行は、セッションが停止したことを証明するものではありません。

引用されたやり取りを見つける

プロジェクト、日付、タイトルの手がかりをもとに「これはどの Session でしたか？」と尋ねられた場合は、まず既存のインベントリを使用します。タイトルと範囲から最有力候補を選びます。タイトルの一致は手がかりにすぎません。これらの手がかりで検索対象が絞られている場合は、コーパス全体のスキャンやプロバイダー横断インデックスから始めないでください。

<skill-dir>/scripts/list_local_history.py \
  --source codex --index-only --cwd <workspace> --include-archived \
  --from-date <YYYY-MM-DD> --to-date <YYYY-MM-DD> --limit 20
<skill-dir>/scripts/read_codex_session.py --session <CANDIDATE_ID> --full

不明な日付の境界は省略します。ワークスペースが不明な場合は、--cwd を --all-projects に置き換えます。日付が示すのは引用されたやり取りが発生した時点であり、Session が作成された時点ではありません。インベントリは作成／更新期間との重複を確認するため、その日に再開された古い Session も候補になります。ロールアウトディレクトリを、その日に作成されたフォルダーに限定しないでください。アセットの日付はメッセージの日付ではありません。

候補を選ぶ際は現在の Session を除外します。読み手の確認済みの ID と、元の話者のタイムラインエントリー内にある引用文を照合します（貼り付けられたアシスタントの返信の場合は、レコード座標を伴う ASSISTANT）。ユーザーがその返信を引用したこと、ツールの結果、または圧縮された要約だけでは、元の発言場所の証明になりません。大規模なブリーフィングでは、以下のプライベートファイルの方法を使い、該当するエントリーをロールとレコード見出しとともに確認します。Session の検索に、無関係な履歴を読むことや古いタスクを続けることは必要ありません。

引用文と ID を確認できたら終了し、ID とソース座標を返します。候補が該当しない場合は、残りの有力候補を試します。リストの切り詰め、タイムスタンプの欠落、インベントリの利用不可、該当候補なしは、不在を意味しません。インデックス検索を絞り込み、その対象範囲を明示します。未加工のコーパス検索には切り替えないでください。

元の入力をそのまま取得

# Global recent window, then group by Session
<skill-dir>/scripts/list_codex_user_inputs.py --recent 200 --language zh

# Expand exact Sessions already shown, preserving their order
<skill-dir>/scripts/list_codex_user_inputs.py \
  --session-id <ID-1> --session-id <ID-2> \
  --per-session 100 --language zh

Markdown は人が読むための形式です。JSON は、フォレンジック用途や機械処理のために保存された文字列値を保持します。重複、行の順序、タイムスタンプ、文言、Session の境界を保持します。タイトルを捏造したり、1 つの Session を意味カテゴリごとに分割したりしないでください。

会話全体の入力を照合

<skill-dir>/scripts/reconcile_codex_inputs.py --session <EXACT_ID> --format json

選択したセッション内で明示的な包含カットオフを指定するには --through-record を使用します。--omit-first／--omit-last は、ユーザーが実際に要求した除外に限って使用します。どちらのオプションも、メッセージが冒頭の指示かフィードバックかを判定するものではありません。欠落を解決した後、番号付きの引用をそのまま示すには --format markdown を使用します。結果フィールド、確認済みの除外、部分的な結果、決定論的なフィクスチャのみの検証については、リンク先の照合リファレンスを読んでください。

Session の正確な証拠と系譜

<skill-dir>/scripts/read_codex_session.py --session <SESSION_ID> --full

期待される出力：# Codex Session Evidence Briefing、確認済みの選択 ID、ルートから子へのフォーク系譜、正確な親のバイト境界、時系列の引き継ぎ、圧縮されたコンテキスト、最新の計画、ツール呼び出し、ファイル、エラー、終了理由、ワークスペースの状態。論理／物理選択と継承される境界については、ロールアウトの ID とフォークの仕様に従ってください。誤った状態 DB の候補は却下し、正確な ID ロケーターを使用します。似たタイトルやファイル名があっても、そこから作業を続けてよい理由にはなりません。ブリーフィングが安全制限に達して失敗した場合も、ブリーフィングは失敗のままです。以下のエクスポータールートを使うのは、検証が要求された結果である場合に限ります。

完全なブリーフィングが 1 つのモデルコンテキストに収まらない場合は、1 回だけプライベートな一時ファイルに書き出し、読み込む前に SHA-256 と行数を記録します。その不変ファイル 1 つがブリーフィング全体です。「ブリーフィング 1 件」は、stdout のペイロード 1 件や単一の巨大なコンテキスト読み込みを意味しません。既存の見出しまたは正確なレコード座標を使って、範囲が重複しない限定範囲を読み、記録した行数に対する読み取り範囲を追跡し、未読の範囲をすべて未確認箇所として報告します。読み取りを異なる切り詰め設定で再実行し、出力を結合して完全に見える時系列を作らないでください。

エクスポーター向けのキャプチャ済みロールアウト検証

エクスポーターで、会話内容を蓄積せずに明示的に選択したバイトプレフィックスを検証する必要がある場合は、同梱の validate_codex_rollout 呼び出し可能オブジェクトを使用してください。 インポートしたり祖先をたどったりする前に、API、準備状態、復旧の契約をお読みください。実際のメタデータと検証済みのエッジを使用してください。履歴をコピーまたは検証しても、実行の所有権が確立されるわけではありません。

元のツールとレコードの証拠

ID またはインデックス検索でセッションを選択した後、別の JSONL パーサーを作成するのではなく、同梱のリーダーで保存済みのツール結果を読み取ってください。

<skill-dir>/scripts/read_codex_session.py --session <ID> --tools --contains '<literal clue>' --format json
<skill-dir>/scripts/read_codex_session.py --session <ID> --record <ORDINAL> --format json

--record を付けずに --tools を指定すると、正確な祖先プレフィックスを使い、ルートから選択対象までの順序で、宣言された完全な論理履歴が展開されます。その scope は logical_history であり、sources にはすべての物理ソースとカットオフが記載されます。各結果には、ソースパス、物理ロールアウト ID、物理的な record 序数、および logical_record の位置が保持されます。paired_call が前のセグメントを指す場合があります。個別のサブエージェントスレッドと添付ファイルのバイトデータは展開されません。

選択した物理ロールアウト内の、空白でないレコードの 1 始まりの序数を複数指定するには、--record を繰り返してください。このセレクターでは scope: selected_rollout_only が維持されます。また、これを --tools と組み合わせると、選択した物理レコードの共通部分が対象になります。--contains は、報告対象範囲内でリテラル部分文字列によるフィルターを行います。どちらのモードでも、すべての出力文字列とフィールドを含む元の保存済みレコードが保持され、内容の墨消しやプレビューの切り詰めは行われません。paired_call は結果に対応する先行コールの位置を示します。外部メッセージの出所を特定する前に、両方の座標を確認してください。ロールラベルだけでは、人間が作成したことの証明にはなりません。

期待される出力には、identity、records_examined、matched_records、ソース座標、および truncated: false が含まれます。要求された序数が見つからない場合は、明示的に失敗します。一致件数がゼロであるという結果は、報告対象範囲にのみ適用されます。--full は引き続き文章によるブリーフィングの切り詰めを制御しますが、ブリーフィングを完全なツール証拠に変えるものではありません。

インデックス化されたコンテンツの検索

インデックスは保存済みの文章から候補を返します。ツール出力、思考、圧縮、および引用行の話者を確認するには、正確なロールアウトを読み取ってください。

<read-claude-code-history-dir>/scripts/history_index.py status
<read-claude-code-history-dir>/scripts/history_index.py recall '<keyword>' \
  --mode bm25 --provider codex --exclude-session <CURRENT_ID>

まず、正確な ID、既知の日付、またはインデックス化されたコンテンツの手掛かりを指定してください。候補のロールアウトは、それぞれの session_meta.id で検証してください。タイムアウトや従来の --from-date フィルターがあっても、raw コマンドがすべてのロールアウトを読み取ることは妨げられません。このコマンドは現在、ライブソースを拒否します。

代替手段：インデックス化された全文検索

個別の ~/.claude-flow-viewer/search.sqlite FTS インデックスを使って、候補となるセッションを見つけることもできます。使用する前に、対象プロバイダーとインデックスの鮮度を確認し、その後、各検索結果を正確なセッションリーダーで検証してください。検索結果は手掛かりであり、証拠ではありません。

sqlite3 ~/.claude-flow-viewer/search.sqlite "
SELECT s.source, s.session_id, s.project_encoded, substr(c.text, 1, 600)
FROM search_chunks_fts fts
JOIN search_chunks c ON c.rowid = fts.rowid
JOIN indexed_sessions s ON s.session_id = c.session_id
  AND s.source = c.source AND s.project_encoded = c.project_encoded
WHERE fts.search_chunks_fts MATCH '\"keyword-one\" OR \"keyword-two\"'
  AND c.kind IN ('prompt','ai-text')
LIMIT 15;"

このインデックスで測定された制約を以下に示します。いずれも、検索結果がゼロの場合の意味を変える要因です。

• まず鮮度の境界を確認してください。 sqlite3 ~/.claude-flow-viewer/search.sqlite "SELECT * FROM search_meta;" を実行すると、last_indexed_at が表示されます。このタイムスタンプより新しいセッションはインデックスにまったく含まれていないため、クエリでは見つかりません。対象範囲に関する説明には、この境界も併記してください。
• search_chunks を直接検索せず、search_chunks_fts を通じて照合してください。 直接クエリを実行すると、約9GBのテーブル全体をインデックスなしでスキャンします。測定では、インデックスを使う経路の0.03秒に対し、26秒かかりました。
• このクエリは全文検索を使用します。 ベクトル類似度ではなく、コーパス内の文字列そのものを検索します。測定したスナップショットでは、sqlite-vecのシャードテーブルが存在していたにもかかわらず、search_embeddings の行数は0でした。ベクトル検索が利用可能だと主張する前に、現在のデータ件数を確認してください。言い換えを検索する場合は、read-claude-code-history のハイブリッド検索インデックスを使用してください。
• このビルドでのFTS5構文。 引用符付きのフレーズは明示的な OR で結合してください。引用符なしの複数語クエリは 暗黙のAND です。空白だけでつないだ2つの語は、両方を含む行にのみ一致するため、検索範囲を広げるはずのクエリが何も返さなくなることがあります。"term-a" OR "term-b" のように記述してください。NEAR/n のスラッシュ構文は構文エラーになります。標準的な2オペランド形式の NEAR(A B, k) はエラーなく解析されます（テストしたクエリの1つでは0行でしたが、これは構文エラーではなく、実際に共起がなかったという結果です。したがって、0行を「NEARが壊れている」と解釈しないでください）。
• unicode61 トークナイザーでは、連続するCJK文字列全体が1つのトークンになります。 そのため、中国語のフレーズが一致するのは、フレーズが連続した文字列全体に一致する場合だけです。技术选型 での測定では、フレーズ検索の結果は10行で、部分文字列の出現数は163件でした。闭门造车 では10行に対し790件でした。1文字が独立したトークンにならないことを決定的に示す結果は、闭 が2行、闭门 が17行だったことです。闭 が独立してトークン化されるなら、その結果がより少なくなることはありません。同じ系統の、より長い文字列では検索精度が大幅に上がります（不要闭门造车 → 314行、出現数790件）。そのため、中国語を検索する場合は、推測できる範囲で最も長く連続した文字列を使ってください。ASCII文字と句読点で区切られた語にはこの問題はありません（technology-selection は、出現数34件に対し35行で一致しました）。中国語の検索結果が0行または少数行でも、不在を意味すると解釈しないでください。ここでの検索漏れは、「一度も話題にしなかった」場合と見分けがつきません。まさにその問題を防ぐために、この検索経路があります。
• ユーザー自身の発言を取得するには、c.kind で絞り込んでください。 prompt はユーザーの入力、ai-text はアシスタントの発言です。thinking、tool-call、tool-result もインデックス化されるため、絞り込まないと主にツール出力が表示されます。
• 検索結果を何かに帰属させる前に、s.source を確認してください。 ここで見つかった検索結果だけでは、Codex による検出とは言えません。
• 現在のセッションを除外してください。 現在のセッションにはこの質問そのものと、それを検索するコマンドが記録されているため、自分自身についてのほぼすべてのクエリに一致します。

IDと系譜の確認ゲート

名前付きSessionについて動作に関する主張をする前に、次の手順を実施してください。

1. ユーザー入力を引用する場合は、プロンプト台帳のSession IDを確認します。
2. 正確なセッションリーダーを使用するか、エクスポーターの場合はキャプチャ済みプレフィックスAPIを使用し、その同一性および系譜に関する契約に従ってからイベントを帰属させます。
3. プロンプトのみ、またはロールアウトのみの欠落がある場合は、明示的に報告します。

確認された失敗には、状態DBが別のロールアウトを指していたプロンプト台帳のSessionや、子ロールアウトのない/fork入力が含まれていました。

読み取り結果の契約

すべての回答で、以下を明記する必要があります。

1. 読み取ったソース — プロンプト台帳、状態 DB、ライブ／アーカイブのロールアウト。
2. 対象範囲 — セッション ID、プロジェクト、内部時刻の範囲。
3. 結果 — 要求された生データの表、タイムライン、または一致項目。
4. ID／系譜の状態 — 検証済み、プロンプトのみ、ロールアウトのみ、または不一致。
5. 不足情報 — 形式不正／読み取り不能なソース、親の欠落、添付ファイルのバイト列の省略、タイムアウト、または未検索の範囲。

「見つからない」という結果は、この対象範囲に限られます。タイムアウトや不完全なスキャンを、否定的な結果として扱わないでください。

ガードレール

• このスキルは読み取り専用とし、再開、アーカイブ、名前変更、削除、修復は行いません。
• codex resume、codex --continue、または新たな実装実験を実行しないでください。
• 数メガバイトに及ぶロールアウトを直接コンテキストに読み込まず、同梱のリーダーを使用してください。
• プロセス名、cwd、書き込みロックがないことから、セッションの状態や所有者を推測しないでください。
• ユーザーから明示的に共有を求められない限り、生の履歴はローカルに保持してください。
• どちらかのインデックスで該当件数がゼロでも、「会話が発生していない」と判断しないでください。プロバイダーの対象範囲と鮮度を確認し、インデックスに登録されていないレコードは不明として報告してください。該当する手がかりが見つかった場合は、該当するロールアウトを正確に読み取って検証してください。

ルーターと従来との互換性

現在の local-conversation-history はプロバイダー横断型のルーターです。プロバイダー固有の Codex 読み取り要求をこのスキルに送りますが、このスキルの ID、系譜、証拠に関する契約に取って代わるものではありません。旧来の統合コマンドの契約は references/legacy_multi_provider_inventory.md に残してあり、Kimi の分岐や過去のフラグが暗黙に削除されないようにしています。プロバイダー固有の Claude の要求は daymade-claude-code:read-claude-code-history にルーティングされます。

現在のスレッドに限定された直接入力カーソル

現在のスレッドへの要求の後に追加された、元のユーザーの直接入力が必要な処理には、prompt_cursor.py を使用してください。要求を提示する前に snapshot を実行し、その後 tail --cursor <snapshot.json> を実行します。アダプターはアカウント所有の正規プロンプト台帳から新しいバイト列のみを読み取り、テキストをデコードする前に現在のランタイムスレッドを選択します。inode、デバイス、オフセットを保持し、ローテーション、切り詰め、不完全なレコード、スレッドの変更、デフォルト以外のソース、未対応のホストを拒否してください。呼び出し側からの台帳／ルートの上書きは受け付けません。台帳のスキーマでは人間が作成したことを証明できません。既知のピアレコードがないことは、限定的な証拠にすぎません。アダプターは、作成者が明確に確立されていないソースレコードを返します。承認として返すことはありません。コンテンツの紐付け、確認構文、無効化、単一試行での消費は、利用する処理側が担います。過去の入力の取得には、既存のリーダーを使用してください。