目的

以前に出した oven-sh/bun#43660 は氷山の一角。「bun 同士のパイプで化ける」は、表に出た症状の 1 つにすぎない
根本の問題は、bun がコンソールのコードページを変えること。コードページは窓ごとの設定で、同じ窓の全プロセスが共有している
変えることで、多くの害が出る。害を 1 つずつ実測で示す（「Issue の骨組み」の害の一覧）
だから、コードページを変えないでほしい。コードページを変えた件そのものを問題として、新しい Issue を出す
そうすれば bun#43660 も同時に直る。新しい Issue と bun#43660 の双方に、相互の関連を書き足す

Issue の骨組み

1. 背景

bun#43660 で、cp932 の窓では bun | bun の出力が化け、終了後に 65001 が残ると報告した。これは症状の 1 つだった。

2. 根本の問題

bun は実行中にコンソールの入力・出力コードページを書き換える。コードページは同じ窓の全プロセスで共有されるため、bun の外にまで影響が及ぶ。

3. 害の一覧と証拠

✅ 観測済み／ ⬜ 未測定。

害	証拠	状態
H1	パイプでつないだ相手の表示が化ける（bun#43660 の症状）。調査の 1.4.2・canary 版、T2・T5	✅ 観測済み
H2	結果が実行のたびに変わる。起動・終了の順で決まる。調査の 3 回の差、T5	✅ 観測済み
H3	終了後に 65001 が窓に残る。調査、T1・T5	✅ 観測済み
H4	同じ窓の別のプロセスが巻き込まれる。cmd が SJIS のスクリプトを読み違え、`pause` などのメッセージが英語になる。調査、T4	✅ 観測済み
H5	ほかの bun が窓を 932 に戻した後に、bun が UTF-8 のバイト列をそのまま書いて化ける（`WriteConsoleW` を使っていない）。調査の 1.4.2 の 3 回目、T5	✅ 観測済み
H6	強制終了すると元に戻らない。T3	✅ 観測済み
H7	bun 同士が直接つながっていなくても起きる（`bun \| node \| bun`）。T5	✅ 観測済み

観測した内容はコードページ試験の結果と bun#43660 の再現にある。H2 の原因（起動・終了の順で決まる）は T5 で確かめた。

4. 依頼

コンソールのコードページを変えないでほしい。画面への出力は WriteConsoleW で UTF-16 のまま渡し、パイプ・ファイルにはバイト列をそのまま書けば、コードページに依存しない（「あるべき姿」）。node と deno が変えずに正しく動くことを、実装できる裏付けにする（T1・T2）。

5. bun#43660 も直る

コードページを変えなければ、H1〜H7 はどれも起きない。bun#43660 の症状（H1）もここに含まれる。

前提とあるべき姿

基準の窓

日本語版 Windows で、開いた直後の cmd の窓（コードページ 932）を基準にする。テストはコードページに一切触らない。

IMPORTANT: AIエージェントのセッションの窓は ConPTY 配下で、開始時点で 65001 になっている。そこで直接流すと基準の窓にならない。テストは conhost.exe で新しいコンソールを起こし、その中で走らせる。結果はファイルに書かせて読む。conhost.exe を名指しするのは、既定の端末が Windows Terminal だと新しい窓も ConPTY 配下になりうるため（未検証）。bun#43660 も Windows Terminal ではなく cmd.exe を直接使った条件で報告されている。

あるべき姿

相手	書き方・読み方
コンソールへの出力	`WriteConsoleW` で UTF-16 のまま渡す
パイプ・ファイルへの出力	UTF-8 のバイト列をそのまま書く
コンソールからの入力	`ReadConsoleW` で UTF-16 として読む
パイプからの入力	届いたバイト列をそのまま受け取る

どれもコードページに依存しないため、書き換える理由がない。T1 で、node と deno がコードページを一度も変えずに 932 の窓へ日本語を正しく出すことを確かめた（内部で WriteConsoleW を使っているかまでは見ていない）。

bun#43660 で報告されていることと、この環境での再現

報告されていること	この環境
開始時のコードページが 65001 でないと、bun \| bun で文字化けする	再現した（安定版・canary 版とも）
片方が node なら起きない	確かめた（T2: 片方が node か deno なら 65001 は残らない）
終了後に窓が 65001 のまま残る	再現した。ただし残らない回もあった

使うランタイム

ランタイム	版	役割
bun	1.4.3+c6da4a4d3	調べる対象（安定版）
bun canary	準備の時点の最新（全件の試験では 1.4.3-canary.1+bbdc5a519）	調べる対象。`_bin/bun-canary/` に置き、PATH を入れ替えて呼ぶ
bun PR #43662	1.4.3-canary.1+6b5271cb1	bun#43660 への修正の PR の版。何が直り、何が残るかを見る。`_bin/bun-pr-43662/` に置き、PATH を入れ替えて呼ぶ
node	v26.10.0	比べる相手
deno	2.9.7	比べる相手

テスト項目

期待値

「あるべき姿」の実装なら、全項目で次のとおりになる。

項目	示す害	期待値
T1	H3	実行前・実行中・終了後のすべてで、入力・出力とも 932 のまま
T2	H1	27 通りすべてで、受け手に UTF-8 のバイト列がそのまま届く（Windows PowerShell 5.1 経由の分は node \| node と同じ結果になる）
T3	H6	強制終了の後も 932 のまま
T4	H4	SJIS の cmd が日本語を正しく出す
T5	H1・H2・H3・H7	起動・終了の順に関わらず、画面は `abc 東京大阪 xyz` と正しく出て、終了後も 932 のまま
T6	全部	安定版・canary 版とも、T1〜T5 の期待値どおり

bun がこの期待値から外れれば、それが Issue の証拠になる
node と deno がこの期待値を満たせば、コードページに触らずに実装できることの裏付けになる
node や deno が外れた場合は、比べる相手として使えるかを見直す

T1. コードページの推移

基準の窓で、実行前・実行中・終了後の GetConsoleCP ／ GetConsoleOutputCP を記録する。実行中の値は各ランタイム自身が FFI で読む（読むだけ）。bun は bun:ffi、node は koffi、deno は Deno.dlopen。期待値は全時点で 932。

T2. パイプの組み合わせ

軸	値
送り手	bun / node / deno
受け手	bun / node / deno
起動元	cmd / pwsh 7 / Windows PowerShell 5.1（いずれも基準の窓の中から起動）

3 × 3 × 3 ＝ 27 通り。受け手は受け取ったバイト列をそのままファイルへ書き、期待する UTF-8 のバイト列と突き合わせる。画面の見た目では判定しない。

NOTE: Windows PowerShell 5.1 は、bun を含まないネイティブコマンド同士のパイプでも非 ASCII が ? になる既知の事象がある。5.1 の行は node | node を基準にし、bun 固有の差だけを見る。

T3. 強制終了後の残留

待機中の bun を taskkill /F で止め、窓が 932 に戻っているかを確かめる。

T4. 同じ窓の隣のプロセスへの影響

bun | bun の直後（通常終了・強制終了）に、SJIS で書いた cmd が日本語を正しく出すかを確かめる。

T5. 順番を固定した再現

2 本以上のプロセスが起動・終了する順番を待ち時間で決め、偶然に頼らずに結果を出す。各プロセスは起動直後・書く直前・終了直前に GetConsoleCP ／ GetConsoleOutputCP を時刻つきでログへ書く（読むだけ）。送る文字列は abc 東京大阪 xyz にする。偶数の文字数（4 文字・12 バイト）で、CP932 として読まれても 2 バイトずつ別の文字に読み替わり、壊れたバイトが残らない。化けると abc 譚ｱ莠ｬ螟ｧ髦ｪ xyz になるため、前後の ASCII と改行は残り、正しい形と化けた形を機械的に見分けられる（node の TextDecoder('shift_jis') による計算。コンソールの表示とは未照合）。

形	順番の決め方	確かめること
`bun \| bun`	起動の順は片側の起動前に `ping -n 2 127.0.0.1 >nul`、終了の順はスクリプト内の `setTimeout`	起動の順 × 終了の順 × 画面に書く／書かない
`bun \| node wait \| bun`	間の node が受け取ったデータを決めた時間だけ持ってから流す	bun 同士が直接つながっていなくても起きるか（H7）
`node \| node wait \| node`	同上	比べる相手
`deno \| node wait \| deno`	同上	比べる相手
bun#43660 と同じ形	順番を決めない（`-e` で 2 本を同時に起動）。10 回流す	結果が回ごとに変わるか（H2）
ww を別の書き方で	ww の順で、受け手が `fs.writeSync(1)` ・ `fs.write(1)` ・ `Bun.write(Bun.stdout)` で画面に書く。bun の版だけ	PR #43662 が手当てしていない書き方で化けるか

仮説（各 bun が起動時に今の値を控えて 65001 にし、終了時に控えた値へ戻す）から予想する bun | bun の結果:

起動の順	終了の順	画面	終了後
送り手が先	送り手が先	化ける	65001 が残る
送り手が先	受け手が先	正しい	932 に戻る
受け手が先	送り手が先	正しい	932 に戻る
受け手が先	受け手が先	正しい	65001 が残る

各組を 3 回ずつ流し、回の順に結果を並べる。経緯は bun#43660 の再現を参照。

T6. 版の比較

T1〜T5 を bun の安定版と canary 版の両方で流す。node ・ deno は基準として版を 1 つに固定し、記録する。

テストの作り

tests/
  codepage.test.ts      T1〜T5 本体（node:test、bun test でも流す）。bun と canary を同じ表の列に並べて T6 にする
  fixtures/
    console.ts          コードページを読むだけの共通部品（bun:ffi ／ koffi ／ Deno.dlopen）
    emit.ts             abc 東京大阪 xyz を console.log で出す送り手
    sink.ts             受け取ったバイト列を画面かファイルへそのまま書く受け手
    hold.ts             受け取ったデータを決めた時間だけ持ってから流す中継（T5 の node wait）
    probe.ts            観測役（node）。コードページを記録し、窓の画面の文字を読み取る
    neighbor-932.cmd    932 用の隣のプロセス役（SJIS ＋ CRLF）
    neighbor-437.cmd    437 用の隣のプロセス役（CP437 ＋ CRLF）
  harness/
    new-console.ts      conhost.exe で新しいコンソールを起こし、その中で実行して終わるまで待つ
    judge.ts            画面・バイト列・コードページの判定と、証拠の置き場の results.jsonl への記録
  manual/
    issue-43660-repro.cmd   bun#43660 と同じ形のコマンドを手で流す（画面を目で見る）
tools/10_setup/
  setup-runtimes.ps1 / .cmd   準備フェーズ。ランタイムを _bin/ に取り、npm ci を流す
  fetch-bun-pr.ts       bun の PR の Windows x64 のビルドを、bun の CI（Buildkite）から取る
tools/40_test/
  run-tests.ps1 / run-tests.cmd   試験実施フェーズ。932 と 437 で、node --test と bun test を流す
tools/50_run/
  summarize-results.ts  証拠の置き場の記録から、結果表の材料を出す
  compare-evidence.ts   research/evidence_last/ と research/evidence/ の判定を比べる
  build-result-tables.ts research/evidence/ から結果資料の表を作り、証拠ファイルと試験コードへリンクする
  verify-issue-repro.ts Issue の本文に載せる再現コマンドを新しい窓で流し、画面を出す

fixtures は bun ・ node ・ deno の 3 つで動く 1 本の .ts にする
判定は出力ファイルのバイト列で行う。出力先は tmp/
同期 API で子を待つ箇所には timeout を付ける
テスト名は再現条件をそのまま書く
期待値は「あるべき姿」にする。bun のケースは直るまで失敗するため todo 扱いにし、失敗を証拠として記録しながら全体は止めない。bun test は todo のケースを実行しないため、bun のケースの証拠は node --test 側で取る
画面の判定は、観測役が ReadConsoleOutputCharacterW で窓の文字を読み取って行う。人が目で見なくてよい

どの PC でも同じ試験を流す

リポジトリを clone した人が、Windows なら誰でも同じ試験を流せるようにする。その PC に入っている bun ・ node ・ deno には頼らない。

準備フェーズ

tools/10_setup/setup-runtimes.cmd（中身は同名の ps1）が、版を決めた実行ファイルを公式の配布元から取り、_bin/ に置く。_bin/ は Git の管理外。すでに置いてあれば取り直さない。

ランタイム	版	置き場
bun	1.4.3	`_bin/bun/`
bun canary	取った時点の最新（版を固定できないので、取った版を記録する）	`_bin/bun-canary/`
node	v26.10.0	`_bin/node/`
deno	2.9.7	`_bin/deno/`
pwsh	7.6.6	`_bin/pwsh/`
bun PR #43662	PR の先頭コミットのビルド	`_bin/bun-pr-43662/`。bun の CI（Buildkite）の成果物を `tools/10_setup/fetch-bun-pr.ts` で取り、SHA-1 を照らし合わせる

取ったあと、_bin/node/ の npm で npm ci を流す（koffi と型チェック用）。

試験実施フェーズ

tools/40_test/run-tests.cmd が set PATH=…\_bin\…;%PATH% で、取った実行ファイルを PATH に置く
where で、bun ・ node ・ deno ・ pwsh が _bin/ の下のものに解決されることを確かめる。違えば止める
各ランタイムの版（bun --revision ・ node -v ・ deno --version ・ pwsh の版）を versions.txt に書く
全件を流す。ケースごとのバッチ（run.cmd）は、実行ファイルを名前だけで呼び、パスは %~dp0 からの相対にする。ユーザ名を含むパスはどこにも入らない

決めたこと

PATH: 取った実行ファイルを、いつも PATH の先頭に置く。PC に入っているものは使わない
bun と canary: どちらも bun の名前なので、PATH を入れ替えて別の回に流す。canary の回は、bun を含むケースだけを流す
開始のコードページ: 932 と 437 の両方で流す。試験専用の窓の中で、最初に chcp してから始める（窓はほかと共有しない）。判定は開始の値を基準にする
隣のプロセス役: 932 用（SJIS で neighbor: 東京大阪）と 437 用（CP437 で neighbor: café）を分ける
pwsh: 取って使う
流す回: コードページごとに 4 回。node --test（bun 安定版・ node ・ deno）、node --test（canary と PR #43662 の版。bun を含むケースだけ）、bun test（node と deno のケース）
ログ: 日時と pid を書かない。各ケースの最初からの経過時間（ms）だけを書き、2 回の結果を diff で比べられるようにする
環境ファイル: 回ごとに environment.json を置き、開始のコードページ・ツール名・ツールの版・実行日時（UTC の Z 形式。例 2026-10-07T03:45:12Z）を書く。日時を書くのはこのファイルだけ

証拠の置き場

置き場	扱い
`research/evidence_last/`	流すたびに上書きする。Git で除外しないが、commit しない
`research/evidence/`	基準として commit する。`evidence_last` を確かめてから写す。再試験のあとは、指示を待たずに写す（ローカルルール）

置く中身: versions.txt、集計（node --test と bun test の分）、ケースごとの run.cmd ・ログ・画面の読み取り・受け手のバイト列
tools/50_run/compare-evidence.ts で 2 つを比べ、判定（✅ ／ ❌）の違いだけを出す。時刻は比べない
保存の前に、ユーザ名を含むパスが入っていないことを検査する

あわせて行うこと

ソースのコメントを、英語を先に、日本語を併記する形にする（ローカルルール）
結果資料の表のセルから、該当する試験コードの行と、research/evidence/ の証拠ファイルへリンクする
commit は、仕組みの変更・証拠・資料のリンク、のように分ける

進め方

deno を導入する（済: 2.9.7）
fixtures とハーネスを作り、T1 で新しいコンソールの仕組みが動くことを確かめる（済）
T1 → T2 → T3 → T4 → T5 の順に 1 項目ずつ足し、そのつど全件を流す（済）
結果の表を英語版・日本語版の資料にまとめ、害の一覧（H1〜H7）の状態を更新する（済: コードページ試験の結果）
T6 で版を比べる（済: 安定版と canary 版を同じ表に並べた）
「Issue の骨組み」に沿って本文案を作り、ローカルルール「Issue と公開」の条件を満たしてから出す（済: bun#44693 として投稿した。本文は Issue bun#44693）
bun#43660 に、新しい Issue への関連を書き足す（済: コメント）
bun#43660 への修正の PR #43662 の版を試験一式で測り、直る害と残る害を #44693 にコメントする（済: 結果資料の結論に PR の列を足した。#44693 へのコメントと PR #43662 へのコメントとして投稿した。本文は Issue bun#44693。PR を見落としたまま #44693 を出したため）
PR #43662 での robobun の問い（65001 が残った回の、全プロセスの起動と終了の順）に、時系列を測り直して答える（済: 60 回流して結果資料に足し、PR #43662 への返信として投稿した。本文は Issue bun#44693）
65001 が残る順番を PR #43662 のソースから導き、PR に伝える（済: 結果資料に足し、PR #43662 への続報として投稿した。本文は Issue bun#44693）
どの PC でも同じ試験を流せる仕組みにし、証拠を research/evidence/ に残す（済。932 と 437 で全件を流し、research/evidence/ に写した。結果資料の表の ✅ ／ ❌ から証拠ファイルへリンクした）
PR #43662 で 65001 が残る順番を、呼び出しを 1 つずつ記録して確かめる。あわせて 437 での時系列と、5.1 が間に入ると残らない理由を測る（済: 結果資料の呼び出しを 1 つずつ記録した結果と時系列の表、T2 の 5.1 の項に足した。PR への続報は送信済みで、robobun から 10/17 に返信があり、それに 6b5271c の結果を返した）

返事を見張る

対象は oven-sh/bun の #44693 ・ #43660 ・ PR #43662。コメント・レビュー・行へのコメント・コミット・ラベル・ close ・ほかからの参照・本文とコメントへのリアクション（こちらのコメントへのものも含む）
ローカルルールの「返事を見張る cron」で確かめる。式と、作り直す決めごとはそちらに置く。繰り返しの cron は、予定より最大 30 分遅れて発火する。遅れの長さはタスクの ID で決まり、毎回同じ（公式の資料）。10/08 は ID の違う 3 つの cron が、6 回ともちょうど 30 分遅れた
node tools/80_ops/check-replies.ts を流す。前回の確認から増えたものだけを出し、投稿した本人の分は除く。前回の確認の時刻は etc/check-replies.json に残る（Git 管理外）
bun の安定版の新版も、同じ確認で見る。releases/latest のタグが前回と変わったら、新着として出す。canary は毎日変わるので見ない。新版が出たら、再試験して資料を更新し、push するところまでやる（ローカルルール「Issue と公開」）。PR #43662 の先頭コミットが変わったときも同じ
新着があれば、リンク先の全文を読み、要旨と、こちらがすべきことの案を報告する。返信を投稿するのは、本文の案を利用者が確認し「送って」と言ってから（ローカルルール「Issue と公開」）
新着があれば、PushNotification でスマホにも知らせる。どの Issue に誰が何をしたかを 1 行で。届かないことがある（Claude Code 側の未解決の不具合。anthropics/claude-code#87003 ほか）
新着が無ければ、1 行だけ返す（✅月/日時:分返事の確認: 新着なし）

bun のコードページ問題を解決したい

目的

Issue の骨組み

1. 背景

2. 根本の問題

3. 害の一覧と証拠

4. 依頼

5. bun#43660 も直る

前提とあるべき姿

基準の窓

あるべき姿

bun#43660 で報告されていることと、この環境での再現

使うランタイム

テスト項目

期待値

T1. コードページの推移

T2. パイプの組み合わせ

T3. 強制終了後の残留

T4. 同じ窓の隣のプロセスへの影響

T5. 順番を固定した再現

T6. 版の比較

テストの作り

どの PC でも同じ試験を流す

準備フェーズ

試験実施フェーズ

決めたこと

証拠の置き場

あわせて行うこと

進め方

返事を見張る