「`cd`はターンをまたいで持続する」(v2.1.265)を無人`claude -p`のstream-json入力で検証したら、v2.1.258と同じ場所に戻っていた

「`cd`はターンをまたいで持続する」(v2.1.265)を無人`claude -p`のstream-json入力で検証したら、v2.1.258と同じ場所に戻っていた Claude Code活用

はじめに

このブログの投稿作業はdaily_post_runner.shからclaude -pを呼び出す無人パイプラインで動いている。2026-09-08の記事では--input-format stream-jsonで1プロセスを維持し、複数ターンを流し込む手法を使った。この方式は「1回のAPI起動で複数の指示を順番に処理させたい」場面(このブログの執筆→検証→採点のような多段階フロー)でよく使う。

そんな中、GitHubのCHANGELOG.md(https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)のv2.1.265(2026-09-08公開)に、まさにこの使い方に刺さる1行を見つけた。

Fixed non-interactive sessions (-p with stream-json input, Agent SDK, cloud sessions) resetting the shell working directory at each new user message; a cd now persists across turns

訳すと「非対話セッション(stream-json入力を使う-p、Agent SDK、クラウドセッション)が新しいユーザーメッセージのたびにシェルの作業ディレクトリをリセットしていたのを修正。cdはターンをまたいで持続するようになった」。手元のバージョンはv2.1.258で、この修正の対象そのもの(-pのstream-json入力)を日常的に使っているので、実際に直っているかを自分の手法で検証した。

結論を先に書く。GitHub CHANGELOG.mdが「修正済み」と明記するv2.1.265を実際にインストールして同じ手順で試したところ、少なくとも今回の再現条件では、v2.1.258と全く同じ「元のディレクトリに戻る」挙動が起きた。 修正が効かなかったと断定はできない(後述の限界を参照)が、「CHANGELOG に書いてあるから直っているはず」を鵜呑みにせず、自分のパイプラインの使い方そのままで確認する価値があった、という記録である。

手順: 自分のパイプラインと同じ形で対照実験する

  1. まず無料で手元のバージョンを確認する。
  2. 手元のv2.1.258で、--input-format stream-jsonで1プロセスを維持したまま2ターンを流し、1ターン目でcd、2ターン目でpwdだけを実行させて、ディレクトリが引き継がれるかを見る。
  3. npm install <パッケージ>@2.1.265 --prefix /tmp/xxx --no-saveでCHANGELOG.mdが修正対象とするv2.1.265を隔離導入し(2026-09-06の記事で確立した手法)、同じ手順をやり直す。
  4. 両者の生JSON出力を突き合わせ、挙動が変わったかを確認する。
  5. 関連するGitHub Issueを検索し、同種の報告がすでにあるかを確認する。

コピペ用プロンプト集

プロンプト1: 手元のバージョン確認(無料・数秒)

前提: claudeコマンドが導入済み。API呼び出しは発生しない。

claude --version

期待結果の例(実測):

2.1.258 (Claude Code)

成功判定: バージョン番号が表示されること。v2.1.265未満なら、このあとのプロンプト2〜4がそのまま「自分の環境で修正前後を比較する」検証になる。

プロンプト2: 手元バージョンでの再現(実費約0.14ドル・2回のAPI呼び出し)

前提: 権限モードが書き込み系Bashコマンドを許可していること(このブログの環境は~/.claude/settings.jsonのpermissions.defaultModeがbypassPermissions)。手元は許可プロンプトが出る設定でもよいが、その場合はcdとpwdの実行を承認すること。

mkdir -p /tmp/cc-cwd-stream && cd /tmp/cc-cwd-stream
cat > turns.jsonl << 'EOF'
{"type":"user","message":{"role":"user","content":[{"type":"text","text":"Bashツールで次を実行して: mkdir -p /tmp/cc-cwd-test && cd /tmp/cc-cwd-test && pwd 。出力されたパスをそのまま教えて。"}]}}
{"type":"user","message":{"role":"user","content":[{"type":"text","text":"もう一度Bashツールで `pwd` だけを実行して(cdコマンドは打たないこと)、出力されたパスをそのまま教えて。"}]}}
EOF
cat turns.jsonl | claude -p --input-format stream-json --output-format stream-json --verbose > stream_out.jsonl
grep -o '"content":"[^"]*"\|"content":\[[^]]*\]' stream_out.jsonl | tail -4

期待結果の例(実測、v2.1.258):

1回目のBashツール実行結果(tool_resultの中身):

/tmp/cc-cwd-test
Shell cwd was reset to /private/tmp/cc-cwd-stream

2回目のBashツール実行結果(pwdのみ):

/tmp/cc-cwd-stream

成功判定: 2回目のpwdが/tmp/cc-cwd-test(1回目でcdした先)ではなく、プロセスを開始した元のディレクトリ(/tmp/cc-cwd-stream)を返せば、CHANGELOG.mdが説明する「新しいユーザーメッセージのたびにシェルのcwdがリセットされる」症状が再現している。実測コスト: total_cost_usdは0.1432526、duration_msは6385だった(stream_out.jsonlのresultイベントで確認できる)。

プロンプト3: v2.1.265を隔離導入して同じ実験をやり直す(実費約0.14ドル)

前提: npmが導入済み。既存のグローバルなclaude本体には触れない。

mkdir -p /tmp/cc265
npm install @anthropic-ai/claude-code@2.1.265 --prefix /tmp/cc265 --no-save
/tmp/cc265/node_modules/.bin/claude --version

期待結果の例(実測):

2.1.265 (Claude Code)

続けて同じ2ターンのstream-json入力を、隔離導入したv2.1.265で実行する。

mkdir -p /tmp/cc-cwd-stream265 && cd /tmp/cc-cwd-stream265
cat > turns.jsonl << 'EOF'
{"type":"user","message":{"role":"user","content":[{"type":"text","text":"Bashツールで次を実行して: mkdir -p /tmp/cc-cwd-test && cd /tmp/cc-cwd-test && pwd 。出力されたパスをそのまま教えて。"}]}}
{"type":"user","message":{"role":"user","content":[{"type":"text","text":"もう一度Bashツールで `pwd` だけを実行して(cdコマンドは打たないこと)、出力されたパスをそのまま教えて。"}]}}
EOF
cat turns.jsonl | /tmp/cc265/node_modules/.bin/claude -p --input-format stream-json --output-format stream-json --verbose > stream_out265.jsonl

期待結果の例(実測、v2.1.265・隔離導入):

1回目のBashツール実行結果:

/tmp/cc-cwd-test
Shell cwd was reset to /private/tmp/cc-cwd-stream265

2回目のBashツール実行結果(pwdのみ):

/tmp/cc-cwd-stream265

成功判定: ここが本記事の核心。CHANGELOG.mdの記述どおりなら2回目のpwdは/tmp/cc-cwd-testになるはずだが、実測ではv2.1.258と同じく元のディレクトリ(/tmp/cc-cwd-stream265)に戻った。total_cost_usdは0.1431232、duration_msは8673。つまりコスト・所要時間ともほぼ同水準で、修正版のはずのバージョンでも症状が変わらなかった。

プロンプト4: 2バージョンの出力を機械的に突き合わせる(無料・手元にJSONがあれば数秒)

前提: プロンプト2・3で作ったstream_out.jsonlとstream_out265.jsonlが手元にあること。

uv run python3 - << 'EOF'
import json

def second_pwd(path):
    lines = [json.loads(l) for l in open(path) if l.strip()]
    results = []
    for d in lines:
        if d.get("type") == "user":
            for b in d.get("message", {}).get("content", []):
                if b.get("type") == "tool_result":
                    c = b.get("content")
                    results.append(c if isinstance(c, str) else c)
    return results[-1]  # 2回目のBash実行結果

a = second_pwd("/tmp/cc-cwd-stream/stream_out.jsonl")
b = second_pwd("/tmp/cc-cwd-stream265/stream_out265.jsonl")
print("v2.1.258 2ターン目pwd:", repr(a))
print("v2.1.265 2ターン目pwd:", repr(b))
print("挙動は同じか(パスの末尾が元ディレクトリ名で終わっているか):",
      a.rstrip().endswith("cc-cwd-stream") and b.rstrip().endswith("cc-cwd-stream265"))
EOF

期待結果の例(実測):

v2.1.258 2ターン目pwd: '/tmp/cc-cwd-stream'
v2.1.265 2ターン目pwd: '/tmp/cc-cwd-stream265'
挙動は同じか(パスの末尾が元ディレクトリ名で終わっているか): True

成功判定: 最後の行がTrueであること。Falseになった場合はあなたの環境では修正が効いている(あるいは実験条件が変わっている)ということなので、そのまま記録しておくと良い比較材料になる。

プロンプト5: 自分のパイプラインへの実務的な回避策(無料・即実行可能)

前提: 複数ターンにまたがるstream-json入力で、ディレクトリ移動を伴う処理を書いている場合。

以下の方針でBashコマンドを書き直して:
「前のターンでcdした場所」に依存せず、ディレクトリを使うコマンドは
毎回 `cd /絶対パス && 実際のコマンド` の形でワンライナーにまとめる。
複数ターンにまたがる状態は、cdではなくファイルや環境変数に明示的に書き出して
次のターンで読み直す設計にして。

期待結果: 既存のスクリプト・自動化プロンプトの中で「前のターンのcdに依存している」箇所が、フルパス指定のワンライナーに書き換えられる。成功判定: 書き換え後のスクリプトを実行し、pwd確認ステップを挟んで意図したディレクトリで実行されていることを確認する。

活用例: どんな場面で効いてくるか

  • 無人claude -pの多段階パイプライン: このブログのdaily_post_runner.shのように、1プロセス内で「執筆→機械チェック→採点」のような複数ターンをstream-jsonで流す構成では、途中のターンでcdした結果を後続ターンが前提にしないよう、各Bashコマンドをcd 絶対パス && ...の自己完結形にしておくと、今回のようなバージョン差に影響されなくなる。
  • Agent SDKでの多段階タスク: CHANGELOG.mdの記述は-pのstream-json入力だけでなくAgent SDK・クラウドセッションも対象に含めている。SDK経由で複数メッセージを送るツールを作る場合も、同じ前提(cwdが持続するとは限らない)で設計しておくと安全。
  • hooksのcwd依存: GitHub Issue #76708(open、2026-07-11作成、「Bash tool cwd does not persist across tool calls; hooks receive stale cwd」)とIssue #83636(open、2026-08-03作成、「Session cwd silently resets to original launch directory」)は、今回の検証と完全に同一の再現条件ではないが、同じ「セッションが認識しているcwdが実態とずれる」という症状クラスを報告している。PreToolUseフックなどでcwdフィールドを信頼する処理を書いている場合、この記事の実験結果と合わせて自分の環境でも確認しておくとよい。

注意点・つまずき所

  • 「CHANGELOG.mdに直った、と書いてある」ことと「自分の使い方で直っている」ことは別。今回の実験はあくまで「cat turns.jsonl | claude -p --input-format stream-json --output-format stream-jsonで2件のJSON Lineを1プロセスに流し込む」という、CLIをそのまま素朴に使う形の再現条件でのみ確認した。Agent SDK経由の呼び出しや、より複雑な会話継続の仕組み(たとえばparent_tool_use_idを使った特定の継続方法)でだけ修正が効くという可能性は否定できない。「今回の条件では変わらなかった」という事実以上の一般化はしない。
  • 原因の断定はしない。CHANGELOG.mdの1エントリが複数のシナリオ(-pのstream-json入力・Agent SDK・クラウドセッション)をまとめて書いている場合、2026-09-05・09-06の記事で確認したとおり、実装の性質によってバージョンを上げても直らない項目が混在することがある。今回のケースもそのパターンの可能性があるが、ソースコードを確認したわけではないので推測にとどめる。
  • 表示されるShell cwd was reset to ...という注記自体は両バージョンに共通の仕様。この文言はBashツールの実行結果に付与される定型の通知で、「次のBashコマンドはこのディレクトリから始まる」という現在地を教えてくれるものだった。つまりCLI自身は正直に「リセットした」と申告しており、隠れたバグではなく可視化された仕様として動いている点は評価できる。
  • 実費と時間: プロンプト2・3はそれぞれ実際のAPI呼び出しを2回行うため、合計で実費約0.28ドル、所要時間は15秒前後×2セット。npm install --prefixによるv2.1.265の隔離導入自体は無料で、数秒程度と短時間で完了する。

締め: 今日の一歩

まずはプロンプト1で自分のclaude --versionを確認し、v2.1.265以降であればプロンプト2相当の実験を1回だけ実機で試してほしい。もし今回と違う結果(2ターン目のpwdがcdした先を正しく返す)が得られたら、それは環境差か実験条件の違いによるもので、貴重な反証情報になる。CHANGELOG.mdの「直った」という1行は執筆の出発点であって、無人パイプラインに組み込む前の検証をスキップしてよい理由にはならない、というのが今回の実測から得られた最大の教訓だった。

出典: GitHub anthropics/claude-code CHANGELOG.md(https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md、v2.1.265エントリ)、GitHub Releases(https://github.com/anthropics/claude-code/releases、v2.1.265は2026-09-08公開)、GitHub Issues #76708・#83636(いずれもopen、関連する症状クラスの報告として引用。本記事の再現実験と同一条件ではない)。

Comments

Copied title and URL