ghostty-use

ghostty-use

再起動前に、識別可能な Claude Code および Codex のターミナルセッションを記録し、再起動後に記録された ID を再度開きます。手動スナップショットでは稼働状況を評価し、自動バックアップでは、対象範囲が一部で稼働状況が不明であることを明示して復元メタデータを保存します。

macOS の Ghostty には、セッション復元用 CLI も AppleScript のタブ辞書もありません（Ghostty 1.3.1、2026-10-04 で確認）。そのため、このスキルでは、その制限を踏まえた実用的な手順を案内します。手動の ps インベントリ → 稼働状況を評価したスナップショット → キーストロークによる貼り付けで復元 → すべての貼り付け失敗を見える形にする自動照合、という流れです。

スナップショット、再構成、ドライラン、照合は、デスクトップを操作せずに実行できます。実際の復元ではグローバルなキーボード／クリップボード入力を使うため、バックグラウンドシェルジョブとして起動してもフォアグラウンド作業になります。復元する前に、明確な Ghostty の引き継ぎ、または既存の明示的なデスクトップ待機許可を使用し、現在のアクティビティを確認して、エージェント間で排他的な操作権を調整してください。その許可が継続して有効な場合は、再度確認を求めずに通知して実行します。入力がない状態だけでは、操作権があることにはなりません。使用中、または状況が不明な場合は、準備と読み取り専用の確認を続けてください。人が操作を引き継いだら入力を停止し、以前のフォーカスを復元してはいけません。ホスト側の拒否には必ず従ってください。

開始時の判断フロー

直前に言ったこと／やりたいこと	実行するコマンド
アップデート／再起動のため終了する（「重启前保存会话」）	snapshot
定期バックアップを行い、変更分のみ保存する（「定期增量快照」）	automatic-snapshots.md を読んでから、ghostty_watch.py install --apply
再起動後、タブを元に戻したい（「恢复之前的窗口」）	適切なスナップショットを使用します。存在しない場合や古い場合は reconstruct を実行し、選択したマニフェストに対して restore --all を実行します
「何か失われた？」／復元後に問題が疑われる	check
特定のセッションを 1 つだけ再度開く	restore --only <id-prefix>
Codex のクォータが残り少なく、アカウントを手動で切り替えつつ、Codex の作業をすべて保持する	codex-account-switch.md を読んでから、switch-prepare → 手動で終了／ログイン → switch-restore

Codex アカウントの切り替え

ユーザーが ChatGPT アカウントを手動で切り替える前に、Ghostty の Codex セッションをすべて保持し、元のセッション ID をまとめて再度開きます。Claude Code は対象外です。この手順を使う前に codex-account-switch.md を読んでください。scripts/ghostty_session.py switch-prepare と switch-restore を使用します。付属の scripts/ghostty_switch.py が、固定マニフェストの選択、アカウント／プロセスの確認、重複を防ぐ再試行、認証結果の個別報告を担います。

python3 <skill-dir>/scripts/ghostty_session.py switch-prepare
# User: finish work, exit the saved Codex TUIs and manually switch account.
python3 <skill-dir>/scripts/ghostty_session.py switch-restore

既定では 1 つのウィンドウ内のタブを使用します。独立したウィンドウが必要な場合に限り、--layout windows を使用してください。引き継ぎ中は、出力された固定マニフェストを保持してください。キャプチャが未解決の場合、アカウントが変更されていない場合、または古いプロセスがまだ動作している場合は、引き継ぎが未完了と見なしてください。この手順でプロセスを終了したり、認証情報を切り替えたりしてはいけません。実際に開く前に、上記のフォアグラウンド操作の条件を適用してください。その引き継ぎがない場合に限り、確認を求めてください。--dry-run と --check は引き続き読み取り専用です。再度開いた ID と、新しいアカウントでのリクエストが成功したかどうかは区別してください。このスクリプトは認証状態を not_checked として報告し、テスト用プロンプトは送信しません。

クイックスタート

# Before quitting (from any directory):
python3 <skill-dir>/scripts/ghostty_session.py snapshot

# After restart (from any directory; needs Accessibility permission for keystrokes):
python3 <skill-dir>/scripts/ghostty_session.py restore        # manual: active only; automatic: full recorded set
python3 <skill-dir>/scripts/ghostty_session.py restore --all  # include waiting/quota/dead/stale/unknown records

スナップショットは ~/.ghostty-session/snapshots/ に保存されます（ホームディレクトリ基準で、再起動後も残ります）。レポートには、稼働中の TUI がすべて記載されます。キャプチャされたセッションに加え、まだトランスクリプトがない新しいタブは unresolved セクションに記載されるため、セッション数がタブ数より少ない場合も、その理由がここで説明され、黙って失われることはありません。 既定では、restore はすでに稼働している ID をスキップします。最後に範囲を限定した自動確認を行い、N/M present、手動で再度開くコマンド、不足している ID のみを含む再試行コマンドを表示します。成功と判断する前に、その結果を確認してください。タブごとの SENT (unverified) は貼り付けの受理を示すものであり、セッションが再度開いた証拠ではありません。同じマニフェストを再実行すると、不足している ID のみが開きます。--dry-run は GUI 操作を行わずにコマンドを表示します。

変更があった場合のみ自動バックアップ

scripts/ghostty_watch.py をインストールまたは実行する前に、 automatic-snapshots.md をお読みください。変更された復元状態のみを保存し、以前のバージョンはすべて保持します。変更がない実行では、スナップショットも定期ログも書き込みません。自動マニフェストには、文字起こしを読み取ることなく Ghostty プロセスの子孫が含まれます。これらの稼働状況は明示的に不明とされ、restore は記録されたセット全体を選択します。UUID のない TUI は自動マニフェストでは未解決のままです。ウォッチャーの範囲を限定したスキャンでは、意図的に文字起こしを読み取りません。これらは手動のスナップショット／チェック／復元で解決します（下記のアンカーポイントに関する箇条書きを参照）。部分的な観測では、見つからない ID が保守的に保持されます。ウォッチャーがアプリやタブを開くことはありません。手動スナップショットでは、アクティブなもののみを復元するデフォルト設定が維持されます。

適切なスナップショットがない場合：復旧マニフェストを再構築する

Codex の ID とインデックスを使った復旧には、保守されている依存関係 daymade-claude-code:read-codex-history を使用してください。現在のホストでその Skill のディレクトリを特定してください。権限があり、daymade-claude-code プラグインが存在しない場合は、ホストの通常のマーケットプレイス手順でインストールしてください。スクリプトはソースチェックアウト、または別途インストールされた兄弟ディレクトリの read-codex-history を検出します。それ以外の配置では、--history-reader <reader-skill-dir> または GHOSTTY_CODEX_HISTORY_READER を使用してください。リーダーまたは状態インデックスが見つからない場合は、明示的に失敗します。代わりにロールアウトコーパスをスキャンしないでください。

# Review candidates without writing state or opening tabs:
python3 <skill-dir>/scripts/ghostty_session.py reconstruct \
  --history-reader <reader-skill-dir> --recent-hours 72 --limit 100 --dry-run

# Build one chosen set in a NEW file; --only accepts unambiguous ID prefixes:
python3 <skill-dir>/scripts/ghostty_session.py reconstruct \
  --history-reader <reader-skill-dir> --since <YYYY-MM-DD> \
  --only <id-prefix-1> <id-prefix-2> --out <recovery-manifest.json>

# Restore the full selected set in one invocation, including waiting/quota rows:
python3 <skill-dir>/scripts/ghostty_session.py restore \
  --snapshot <recovery-manifest.json> --all

再構築では、任意の --snapshot（指定がない場合は、存在すれば最新のもの）と、範囲を限定した最近のインデックス付き Codex 候補がマージされます。所有するリーダーを使って内部のロールアウト ID を検証し、各行に past-snapshot または indexed-terminal-candidate のラベルを付けます。ターミナルの証拠となるのは source=cli または originator=codex-tui です。実際の TUI では source=vscode と報告される場合があります。--terminal-source と --terminal-originator を使うと、受け入れるメタデータ値をカスタマイズできます。サブエージェントは、ファイル名のアンダースコアではなく、所有するインベントリのメタデータに基づいて除外されます。--codex-home は、デフォルト以外の Codex ストアを選択します。

過去のスナップショットに含まれていたことから分かるのは、そのセッションがそのスナップショットに記録されていたことだけです。インデックス付きのターミナル候補から分かるのはターミナルで起動されたことだけであり、シャットダウン時にそのタブが稼働中だったことではありません。タイムスタンプとタイトルを確認し、復元するセットを選択してください。--limit は、調査するインデックス付き候補数の上限です。必要な場合のみ、検出範囲を広げてください。スナップショットがない場合、Claude の所属状況は不明のままです。 再構築で Claude セッションが検出されることはありません。網羅的な復旧であると主張せず、既知のスナップショットに含まれる明示的な Claude の記録を保持してください。

新しいマニフェストによって snapshots/latest.json が変更されることはなく、既存の出力ファイルが上書きされることもありません。終了コード 0 は選択された証拠が検証済みであることを示します。終了コード 1 は、マニフェストに確認が必要な却下候補が記載されていることを示します。終了コード 2 は、入力が無効であるか、証拠を利用できないことを示します。ドライランの出力は、確認用の JSON です。

手動スナップショットでセッションごとに記録される内容

• アンカー：存在する場合は、プロセスのコマンドラインに含まれるセッション UUID です（プロセス名では決して照合しません。argv[0] は claude のみの場合と /usr/local/bin/claude の場合があり、名前で照合した結果、2026-10-04 に「すべてのセッションが消えた」という誤報が 2 件発生しました）。新しい TUI の argv には UUID が含まれないため（再開／フォーク時にのみ書き込まれます）、トランスクリプトの保存先からアンカーを特定します。同じ cwd のプロジェクトバケット内で、プロセスの開始時刻以降に作成されたセッションファイルを使い、内部 ID を検証します（2026-10-07：稼働中セッション 25 件のうち 11 件は新しい TUI で、argv のみの照合では検出できませんでした）。同じバケット内に複数の新しい TUI がある場合、トランスクリプトは重複しないように割り当てられます（TUI ごとにファイル 1 件）。判断できない競合（同距離の割り当て要求）がある場合は、推測せず未解決セクションに残します。どちらの方法でも一致しない稼働中の TUI は、スナップショットレポートに未解決の行として表示されます。見える状態にし、黙って除外することはありません。
• 稼働状況：セッションファイルの 内容 から読み取った、最後に実際に操作された時刻です。ファイルの mtime は使用しません（アイドル状態の TUI もファイルに触れ続けるためです。2026-10-04 には「今日の午後までアクティブ」という読み取りが、ファイル内のタイムスタンプでは 03:21 に終了していたことで否定されました）。
• チャネルの健全性：Claude のトランスクリプト末尾に「Login expired」を含む構造化された isApiErrorMessage がある場合は dead-channel です。そのようなタブを復元すると履歴は再び開きますが、セッションは /login で停止するため、スナップショットではスキップできるようにその状態を示します。エラーについて単に 話している だけの会話内の文章は該当しません（以前、「Login expired」について一度話した健全なセッションが、このルールなしでは誤分類されました）。
• プロファイル：存在する場合は --settings .../settings/<name>.json から解析し、それ以外は direct です。

復元の仕組みと制限事項

• 再度開く操作では、Ghostty をアクティブにする → Cmd+T → 再度開くコマンドをクリップボードから貼り付ける → Return の順に実行し、欠落したセッションごとにタブを 1 つ開きます。その後、必須の自動照合を行います。キー入力による貼り付けはタイミングに左右されます。Cmd+T と貼り付けの間に割り込みが入ると、コマンドが通知なしに失われ、空のタブが残ります（2026-10-04 に計測）。自動チェックはこれを可視化するためのものです。決して省略せず、貼り付けの戻りコードだけで成功と判断しないでください。
• 貼り付けを行う前に、照合が完了するまでキーボードとマウスに触れないようユーザーに伝えてください。スクリプトも最初の GUI 操作の前にこの注意を繰り返します。
• osascript のキー入力（System Events）には アクセシビリティ権限 が必要です。現在のホストが Ghostty UI の自動操作を拒否した場合、回避するためにチャネルを切り替えないでください。選択したマニフェストと、ユーザーが実行する正確な復元コマンドを用意し、ユーザーが実行した後に読み取り専用の check --snapshot <manifest> --strict を使ってください。
• ウィンドウのグループ化は復元できません。Ghostty の macOS アクセシビリティインターフェイスでは、タブとウィンドウの対応関係を取得できません。すべてのタブは 1 つのウィンドウに再度開かれます。必要に応じて手動で並べ替えてください。
• codex 自身が見つけられなくなったロールアウトファイルは no-artifact と表示されます。これらを復元すると、同じ codex resume <id> が再実行され、ベストエフォートでの復元になります。

プロファイル環境のマッピング（任意）

Claude プロファイルが環境変数（例：CLAUDE_CONFIG_DIR）を介して設定を適用する場合は、~/.ghostty-session/profile-env.json にプレフィックスを記録して、復元したタブが同じプロファイルコンテキストで起動するようにします。

{"research": "CLAUDE_CONFIG_DIR=~/.claude-profiles/research", "family": "HTTP_PROXY=http://127.0.0.1:7890"}

これがない場合、復元では取得済みの設定、プロファイル、権限／モデルのフラグが再適用されます。argv 以外のプロセス環境は不明です。このマッピングはスキルバンドルの外部にあるユーザー固有のデータであり、デフォルトのマッピングは含まれていません。

トラブルシューティング

症状	原因／対処
restore が STILL MISSING を報告する	表示された不足分のみを対象とする再試行を実行するか、新しいタブで正確な再オープンコマンドを手動で実行してください
Codex セッションで no-artifact が表示される	検証済みのインデックス済みセッションに使用可能なロールアウトがありません。再開はベストエフォートのままです
Codex の稼働状態が unknown になる	リーダー／インデックスを利用できないか、ID が曖昧です。最初に一致したファイル名を選ぶのではなく、依存関係／ストアを解決してください
dead-channel セッションが復元される	想定どおりです。履歴は再度開きますが、セッションは /login で停止します。再認証するか、プロバイダーを切り替えてください
check では存在すると表示されるのに、タブが空に見える	別の稼働中プロセスがすでにそのセッション ID を使用しています（例：別のタブで再開した場合）
osascript がキー入力を拒否する	アクセシビリティ（System Events）の権限を付与してください。osascript -e 'tell application "System Events" to get UI elements enabled' で確認してください
新しく開いたタブがセッション一覧に表示されない	新しい TUI には argv UUID がなく、トランスクリプトファイルは最初のメッセージとともに作成されます。それまでは未解決の稼働中 TUI として表示されます。最初のメッセージがタブを開いてから 20 分を超えて届いた場合、生成時刻の判定期間を過ぎているため、仕様上そのタブは未解決のままになります

詳細

• references/session_liveness.md — ストレージのレイアウト （Claude プロジェクト／Codex セッション）、トランスクリプトの構造、再開時のフォークの命名、 稼働状態のルールと、その背景にある誤分類のケースについて説明します。稼働状態の結果が 不自然な場合や、アプリの更新後にレイアウトが変わった場合に参照してください。
• references/restore_mechanics.md — Ghostty に CLI／AX による復元経路がない理由、キー入力の貼り付けプロトコル、照合設計、 ウィンドウグループ化の境界について説明します。復元経路を変更する前に参照してください。