要点

1. bun は起動時にコンソールのコードページを 65001 に切り替え、終了時に控えた値へ戻す。コードページはコンソールに属し、つながる全プロセスで共有される。ソース: init()（output.rs の 561〜567 行）と restore()（output.rs の 517〜524 行）。証拠、bun が動いているあいだのコードページ: 932 ／ 437（T1）
2. 1 つの窓で 2 本の bun が動くと、互いの控えを上書きする。出力が化け、窓に 65001 が残り、同じ窓のほかのプログラムが壊れる。証拠: 化けた画面 932 ／ 437（T5）、壊れた隣のプロセス 932 ／ 437（T4）、強制終了 932 ／ 437（T3）
3. bun#43660 への Open の修正 PR #43662 は、原因を取り除かない。console.log の出力は直すが、動いているあいだは窓を 65001 にしたまま（932 ／ 437）、強制終了では 65001 が残り（932 ／ 437）、fs.writeSync(1) ・ fs.write(1) ・ Bun.write(Bun.stdout) は化け（932 ／ 437）、戻し方は、順番を決めない形でまれに競合に負ける（時系列）
4. node と deno はコードページを一度も変えず、すべてのケースで正しく出す: node 932 ／ 437、deno 932 ／ 437（T1）

依頼（bun#44693）: コンソールのコードページを一切変えず、画面への出力はすべて WriteConsoleW で書いてほしい。判定は、窓が 932（日本語版 Windows）で始まっても 437（英語版 Windows）で始まっても同じだった。詳しくは 結論、試験の流し方は 条件 にある。

結論

bun は、起動した瞬間（スクリプトが動く前）に窓の入力・出力コードページを 65001 に変え、終了時に「起動時に控えた値」へ戻す。この動きから、計画の害 H1〜H7 がすべて起きることを確かめた。node と deno はコードページを一度も変えず、すべてのケースで正しく動いた。

行は重要な順に並べた。PR #43662 のあとも残る害を先に置く。

PR #43662（bun#43660 への、Open の修正）

PR #43662 は、bun_sys::write を通る画面への出力を WriteConsoleW にし、終了時は控えた値が 65001 でないときだけ戻す。CI の Windows x64 のビルドを、同じ試験一式で流した。bun#43660 で報告した症状は直るが、起動時に 65001 にすることは残るため、共有の状態を変えることから起きる害は残る。

• bun が動いているあいだ、窓につながる全プロセスにとってコードページは 65001（T1）
• 強制終了すると 65001 が残り、そのあと同じ窓で動くスクリプトは読み違える（T3）
• fs.writeSync(1) ・ fs.write(1) ・ Bun.write(Bun.stdout) は WriteFile のままなので、ww の順では化ける（T5）。PR の説明文とレビューにも、そう書かれている
• 「自分が変えたコードページだけを戻す」でも、競合に負けることがある。2 本とも終わったあと、入力側か出力側の片方だけが 65001 のまま残る。起きる頻度は回ごとに大きく変わり、120 回で 0 回のときも、60 回で 3 回のときもあった。時系列を参照。PR のソースから順番も導いている
• 2026-10-16（JST）に PR へ入ったコミット 6b5271c は、起動時に窓がすでに 65001 なら SetConsoleOutputCP と SetConsoleCP を呼ばない。437 や 932 の窓は、これまでどおり 65001 に書き換える。この資料の結果はこのコミットより前の版で測ったもので、このコミットでは bun#44693 の求める実装にならない。このコミットを含む版（先頭コミット 6b5271cb1）で、932 と 437 の全件を流し直したところ、PR の版の判定は 576eb251a のときと 1 件も違わなかった。順番を決めない回（asis）は 932 と 437 で 60 回ずつ、すべて正しく出て、コードページも戻った。強制終了で 65001 が残ることなど、PR のあとも残る害も変わらない

パイプを流れるデータそのものは、どの組み合わせでも壊れなかった（T2）。害はすべて、窓のコードページという共有の状態を書き換えることから起きている。順番を決めたケースは、安定版と canary 版ですべて同じ判定になり（T6）、932 と 437 でもすべて同じだった。

関連する PR

PR #43662 での robobun の返信に出てきたもの。2026-10-10 の時点で、どちらも open で、マージされていない。

• PR #38140（robobun、「メンテナーの確認待ち」）: コンソールの標準入力を、ReadFile ではなく ReadConsoleW で読む。いまは REPL ・ prompt() ・ alert() ・ confirm() ・ bun init ・ bun update -i ・ bun - が ReadFile で読み、入力側のコードページで変換される。Windows 10 / Server 2019 の conhost では、65001 での変換が ASCII 以外の入力を壊す。process.stdin ・ Bun.stdin ・ fs.readSync(0) は libuv を通るため影響を受けない。robobun によれば、起動時に 65001 にするのをやめるには、入力側がいまそれに頼っているため、この PR が先に要る。PR 自身は「壊れているのは ANSI 版の変換で、コードページではない」と書いている
• PR #42819（dylan-conway）: Windows で libuv を外し、I/O 完了ポートの独自のイベントループにする。パイプ ・ コンソール ・ ファイルは src/io/windows/ に移る。robobun によれば、これのあと fs.writeSync ・ fs.write ・ Bun.write の書き込みの手当ては src/sys/windows/fs.rs::write_at 1 か所で済む。直る不具合の一覧に「別のプロセスがコードページを戻した後、process.stdout.write が化けていた（console.log はまだ化ける）」があり、ここで測った害と合う

bun のソースの該当箇所

• init()（output.rs の 561〜567 行）が GetConsoleOutputCP ／ GetConsoleCP の値を控え、SetConsoleOutputCP(65001) ／ SetConsoleCP(65001) を呼ぶ
• restore()（output.rs の 517〜524 行）が終了時に控えた値へ戻す
• ソースのコメント にも「強制終了されると戻らないことがある」とある（H6）

リンクはいまの main を指す。T5 の時系列は、このコードとそのまま一致する。各プロセスは起動時に見えた値を控えるので、2 本目は 65001 を控える。

T1. コードページの推移

1 本だけを窓で動かし、画面に abc 東京大阪 xyz を出す。値は 入力/出力。

試験コード: T1（codepage.test.ts の 35〜51 行）

• bun は、スクリプトの最初の行が動く時点で、すでに 65001 にしている。画面に何も書かなくても変える
• node と deno は開始のコードページのまま、日本語を画面に正しく出した。コードページを変えなくても正しく表示できることの裏付けになる
• 1 本だけなら、bun も終了時に開始の値へ戻すので、問題は表に出ない

T2. パイプの組み合わせ

送り手と受け手を同時に起動し、受け手は受け取ったバイト列をファイルに書く。各セルは「バイト列、終了後のコードページ」を、932 で始めた窓と 437 で始めた窓の順に並べたもの。

試験コード: T2（codepage.test.ts の 53〜81 行）

起動元ごとのコマンドの組み立て: 58〜61 行

• パイプを流れるバイト列は、どの組み合わせでも壊れなかった
• bun 同士を cmd ・ pwsh 7 から直接つなぐと、終了後に 65001 が残った（H3）。片方が node か deno なら残らない。bun#43660 の「片方が node なら起きない」と合う
• Windows PowerShell 5.1 は、どの組み合わせでも日本語を ? に置き換える（node | node でも同じ。5.1 自身の事象）。5.1 の列は node | node と同じバイト列なら ✅ とした。5.1 が間に入ると 65001 は残らなかった。5.1 は 2 本の bun を同時に動かさないため。同じ形を 5.1 経由で 20 回流して見張ると、20 回とも、送り手の bun が終わってから受け手の bun が起動した（間は 11〜22 ms。1 回目の watch.ndjson、results.jsonl）。寿命が重ならないので、一方が控える値に他方の 65001 が入らない

T3・T4. 強制終了と隣のプロセス

T3. 強制終了

画面に書いたあと待機している 1 本を taskkill /F で止める。

試験コード: T3（codepage.test.ts の 83〜102 行）

bun は終了時に戻す作りのため、強制終了されると 65001 のまま残る（H6）。そのあと同じ窓で動く cmd は、自分のスクリプトを UTF-8 として読み違えて化ける（H4）。

T4. 通常終了の後

bun | bun が普通に終わった後（2 本の寿命が重なり、送り手が先に終わる順）の窓。

試験コード: T4（codepage.test.ts の 104〜121 行）

bun の窓の画面（左が 932、右が 437）:

abc 譚ｱ莠ｬ螟ｧ髦ｪ xyz          abc µ¥▒Σ║¼σñºΘÿ¬ xyz
--- tail ---                  --- tail ---
Active code page: 65001       Active code page: 65001
neighbor: �������             neighbor: caf�

node で同じことをした窓の画面（左が 932、右が 437）:

abc 東京大阪 xyz              abc 東京大阪 xyz
--- tail ---                  --- tail ---
現在のコード ページ: 932      Active code page: 437
neighbor: 東京大阪            neighbor: café

日本語版 Windows の chcp は、出力側が 65001 になると英語のメッセージ（Active code page）を出す。bun ・ canary とも、強制終了しなくても同じ窓の隣のプロセス役と chcp まで巻き込んだ（H4）。

T5. 順番を固定した再現

2 本目の起動を約 1 秒遅らせ、終了の順は待ち時間で決める。2 本の寿命は必ず重なるようにした。各組 3 回。セルは「画面またはバイト列 ／ 終了後に開始のコードページ」を、932 と 437 の順に並べたもの。順番ごとの予想は 計画の T5 にある（ww は化けて 65001 が残る、wr と rw は正しい、rr は正しいが 65001 が残る）。

試験コード: T5（codepage.test.ts の 123〜210 行）

bun 1.4.3 と canary の結果は、932 と 437 のどちらでも、すべての組で計画の予想と一致し、3 回とも同じだった。順番さえ決まれば結果は決まる。PR #43662 の版は、受け手が process.stdout で書くときはどの順でも正しかった。一方、受け手が同じ文字列を fs.writeSync(1) ・ fs.write(1) ・ Bun.write(Bun.stdout) で書く最後の 3 行は、どの版でも化ける。これらの API は WriteFile のままのため。この 3 行は bun の版だけで流している（Bun.write は bun にしか無い）。

化ける順番での時系列（bun 1.4.3、ww ・ 画面、932）

このログ から。値は 入力/出力。w は送り手、r は受け手、probe は観測役の node。437 で流した回も、932 が 437 に替わるだけで同じ形になる（ログ）。

   0ms probe  窓の前          932/932
  45ms w      起動直後        65001/65001   ← 送り手が 932 を控えて 65001 にする
  47ms w      書く直前        65001/65001
1093ms r      起動直後        65001/65001   ← 受け手は 65001 を「元の値」として控える
2050ms w      終了直前        65001/65001   → 送り手が終了し、控えた 932 に戻す
2854ms r      書く直前        932/932       ← 受け手は 932 の窓に UTF-8 のバイト列を書く（化ける）
2860ms r      終了直前        932/932       → 受け手が終了し、控えた 65001 に戻す
2989ms probe  窓の後          65001/65001   ← 65001 が残る

• 受け手の bun は、窓が 932 のときに UTF-8 のバイト列をそのまま書いた。画面に出す文字を WriteConsoleW で渡していれば、コードページに関係なく正しく出たはずである（node ・ deno は 932 でも 437 でも正しく出している）
• relay では、間の node は何も変えていない。それでも 2 本の bun の寿命が重なるだけで同じことが起きた（H7）

T5. bun#43660 と同じ形

bun#43660 と同じ形で、2 本を同時に起動し、順番を決めずに 10 回流した（PR #43662 の版は 60 回）。文字列は \u エスケープで渡した abc 東京大阪 xyz（deno は deno eval）。

bun -e "console.log('abc \u6771\u4eac\u5927\u962a xyz')" | bun -e "process.stdin.pipe(process.stdout)"

試験コード: bun#43660 と同じ形（codepage.test.ts の 140〜161 行）

• 同じコマンドでも、bun は回ごとに結果が変わり、化ける回数も流すたびに変わった（H2）。2 本のどちらが先に起動・終了するかで決まり、その順は OS の都合で毎回揺れる
• bun#43660 で「化ける」と報告した現象は、この揺れのうち化ける側を見たものだった
• PR #43662 の版は 120 回とも正しく出し、コードページも毎回戻した。ただし、別の日には 20 回中 1 回、出力側を 65001 のまま残した（2026-10-07 の 6 回目）。下の時系列 を参照
• 先頭コミット 6b5271cb1 の版を、順番を決めずに、932 と 437 で 300 回ずつ流し、見張り役も付けた。さらに、CPU を 8 本の空回しで埋めた中でも 300 回ずつ流した。合わせて 1,200 回、すべて正しく出て、コードページも毎回戻った。証拠は 932（負荷なし） ・ 932（負荷あり） ・ 437（負荷なし） ・ 437（負荷あり）
• 負荷が隙間を広げることは、前の版（576eb251a）を負荷ありの 932 で 100 回流して確かめた。3 回（21 ・ 70 ・ 92 回目）、コードページが戻らなかった（証拠）。同じ負荷の中で 6b5271cb1 は 600 回 0 回なので、失敗の割合が前の版の 3% のままなら、600 回すべて成功する確率は 8000 万分の 1 ほどになる。この試験は、競合に負けることを見つけられる。失敗しなかったのは、たまたまではない。ただし、試験で確かめたのはこの形（bun | bun）だけで、すべての順番を証明したものではない

窓の全プロセスの時系列（PR #43662）

コードページが変わったまま残ったとき、窓にどのプロセスがいたかを見るため、同じコマンドを PR #43662 の版で、932 から 60 回流し直した。その間、同じ窓に node の見張り役をつないだ。見張り役は GetConsoleProcessList ・ GetConsoleCP ・ GetConsoleOutputCP を読み続け、プロセスの出入りとコードページの変化を、すべて UTC の時刻で記録した（watch.ndjson）。node はコードページを変えない（T1）。

同じ形を、見張り役の有無を変えて何度か流した。開始のコードページに戻らなかった回数は、日によって大きく変わる。うまくいった回も、選ばずにすべて載せる。

437 で始めても同じように残った。残った側は 2 回とも入力側で、2026-10-10 の 45・51 回目と同じ形だった。

2026-10-11 の 9 回目は、下の 19 回目と同じ形だった。R は W が 65001 にした 7 ms 後に起動し、終了後は入力 932 ・ 出力 65001 で残った。以下は 2026-10-10 の 60 回の分析。

ほかの 57 回は 932 / 932 に戻った（results.jsonl、environment.json）。3 回の bun の行だけを抜くと（UTC）。W は送り手 bun -e "console.log(...)"、R は受け手 bun -e "process.stdin.pipe(process.stdout)":

run 19
13:39:12.205  attach  W
13:39:12.208  codepage in 932   / out 65001
13:39:12.209  codepage in 65001 / out 65001
13:39:12.216  attach  R
13:39:12.223  codepage in 932   / out 65001
13:39:12.226  detach  W
13:39:12.226  codepage in 65001 / out 65001
13:39:12.263  codepage in 932   / out 65001
13:39:12.266  detach  R
              (left at in 932 / out 65001)

run 45
13:39:50.176  attach  W
13:39:50.179  codepage in 932   / out 65001
13:39:50.181  codepage in 65001 / out 65001
13:39:50.189  attach  R
13:39:50.192  codepage in 65001 / out 932
13:39:50.194  detach  W
13:39:50.227  detach  R
              (left at in 65001 / out 932)

run 51
13:39:58.957  attach  W
13:39:58.959  codepage in 932   / out 65001
13:39:58.960  codepage in 65001 / out 65001
13:39:58.970  attach  R
13:39:58.974  codepage in 65001 / out 932
13:39:58.975  detach  W
13:39:59.011  detach  R
              (left at in 65001 / out 932)

• 65001 の間に起動した 3 本目のプロセスはいない。bun 2 本だけで、コードページが変わったまま残った
• 3 回とも、2 本目の bun は、1 本目が 65001 にした 8〜11 ms 後に起動しており、2 本の寿命は重なっていた
• 残るのは出力側（19 回目）のことも、入力側（45・51 回目）のこともある
• 見張り役は数 ms ごとに読むため、ごく短い変化は記録から抜けているかもしれない

PR のソースから導いた順番

試した版は PR の先頭コミット 576eb251a。コードページを変えるのは、その output.rs だけ:

• init()（output.rs の 581〜585 行）は、別々の 4 つの呼び出しで動く。出力側を控える、出力側を 65001 にする、入力側を控える、入力側を 65001 にする
• restore()（output.rs の 536〜544 行）は、出力側、入力側の順に控えた値へ戻す。ただし控えた値が 65001 の側は戻さない

呼ぶのが W と R だけなら、どの終わり方にも、それを生む順番は 1 つしかない:

• 入力側が 65001 で残る（45・51 回目）: 最後の入力側の変更が、誰も戻さない 65001 への変更でなければならない。W は 932 を控えたので、W の後始末は入力側を 932 にする。その後に来られるのは R の「入力側を 65001 にする」だけで、R が戻さないのだから R は 65001 を控えている。順番は、R が入力側を控える（65001）→ W が終わって入力側を 932 に戻す → R が入力側を 65001 にする。W の後始末が、R の「控える」と「変える」の間に入った
• 出力側が 65001 で残る（19 回目）: 出力側で同じ順番が起きた。R が出力側を控える（65001）→ W が出力側を 932 に戻す → R が 65001 にする。入力側が戻ったのは、R が入力側を控えたのが W の後始末の後（932）で、R の後始末が .263 に戻したため
• どの回も原因は同じ。R の「控える」と「変える」が 1 つの操作になっておらず、その間に W の後始末が入る。すると R は 65001 を「元の値」として控え、PR の判定は 65001 を控えた側を戻さない

ここまではソースと時刻からの推論。見張り役にはどのプロセスが呼んだかは見えず、R の「控える」と「変える」の間は読み取りの間隔より短い（19 回目で、出力側が 932 になってまた 65001 に戻った変化は記録に出ていない）。そこで次に、呼び出しを 1 つずつ記録した。

呼び出しを 1 つずつ記録した結果

W と R をそれぞれ cdb（WinDbg 1.2610）の下で動かし、kernelbase の GetConsoleOutputCP ・ SetConsoleOutputCP ・ GetConsoleCP ・ SetConsoleCP にブレークポイントを置いた。呼ばれるたびに、プロセス ・ 値（Set は引数、Get は戻り値）・ 呼び出し元の番地を記録して、そのまま続行させた（trace-writer.ndjson ・ trace-reader.ndjson）。見張り役も同時に動かした。932 から 40 回流し、3 回で出力側が 65001 のまま残った。

6 回目（UTC）。W は pid 30744、R は pid 55480:

21:30:27.486  W  GetConsoleOutputCP -> 932     (saves 932)
21:30:27.500  W  SetConsoleOutputCP(65001)
21:30:27.509  W  GetConsoleCP       -> 932
21:30:27.511  W  SetConsoleCP(65001)
21:30:27.514  R  GetConsoleOutputCP -> 65001   (saves 65001)
21:30:27.525  W  SetConsoleOutputCP(932)       (W restores output)
21:30:27.527  W  SetConsoleCP(932)             (W restores input)
21:30:27.528  R  SetConsoleOutputCP(65001)
21:30:27.537  R  GetConsoleCP       -> 932
21:30:27.539  R  SetConsoleCP(65001)
21:30:27.594  R  SetConsoleCP(932)             (R restores input only)
              (left at in 932 / out 65001)

• 上で導いた順番がそのまま記録された。R が出力側を控える（65001）→ W が出力側を 932 に戻す → R が出力側を 65001 にする。R の後始末は入力側だけを戻し、65001 を控えた出力側は戻さなかった
• 見張り役の記録とも合う（.531 に出力 932、.533 に出力 65001 へ戻る）
• 呼び出し元の番地は、W と R で同じだった。控えて変える 4 つは …989ceb ・ …989cfc ・ …989d01 ・ …989d12、出力側の後始末は …989b72、入力側の後始末は …975511。どちらの bun も、同じ初期化と同じ後始末の箇所から呼んでいる
• 残った 3 回とも、R の GetConsoleOutputCP が 65001 を返し、R は出力側を戻さなかった。戻った 37 回のうち 14 回は、どちらかが一方の 65001 を控えていたが、もう一方の後始末がその後に来たため戻った

デバッガは呼ばれるたびに bun を止めるので、競合の割合はデバッガなしの回とは比べられない。時刻は 2 つのデバッガがそれぞれ記録したもので、2 本の間の前後は数 ms ずれることがある（21 回目は、記録上の時刻だけを見ると R が控えたのが W の後始末の後になっている）。値（何を控えたか）は、このずれの影響を受けない。デバッガは、出力を隠す前に名乗りを出すため、W の分はその名乗りがパイプに入り、R が画面に出している（screen.json）。

証拠（6 回目）: trace-writer.ndjson、trace-reader.ndjson、watch.ndjson。40 回分:results.jsonl。コード: tools/50_run/asis-timeline.ts --trace、tools/50_run/cdb-trace.js、まとめは tools/50_run/summarize-trace.ts

コード: 見張り役（watch.ts）、流す側（asis-timeline.ts）

条件

判定の方法

• コードページ: 各プロセスが起動直後・書く直前・終了直前に GetConsoleCP ／ GetConsoleOutputCP を読む。窓の前後は観測役の node が読む（T1 で node がコードページを変えないことを確かめている）
• 画面: 観測役が ReadConsoleOutputCharacterW で窓の文字を読み取る。人の目には頼らない
• 隣のプロセス: 各ケースの最後に、同じ窓で chcp と隣のプロセス役の cmd を流す。cmd は開始のコードページで書いてある（932 用は SJIS の neighbor: 東京大阪、437 用は CP437 の neighbor: café）
• バイト列: 受け手が受け取ったバイト列をそのままファイルに書き、正しい UTF-8 かを見る

✅ 期待どおり（あるべき姿と同じ） ／ ❌ 期待と違う。下の表の ✅ と ❌ は、1 つ 1 つがそのケースの証拠ファイルへのリンクになっている。画面（screen.json）、コードページの記録（log.jsonl）、受け取ったバイト列（out.bin）のどれか。

証拠

証拠はすべて research/evidence/ にあり、ケースごとに 1 フォルダ（cp<コードページ>/<bun か bun-canary>/<流した道具>/<ケース>/）。各フォルダには、流したバッチ（run.cmd）・ログ・画面と、あれば受け取ったバイト列がある。ログには日時も pid も無いので、2 回の結果を diff で比べられる。実行日時と道具の版は、回ごとの environment.json にだけある。

• 932: bun 安定版、bun canary、bun PR #43662、bun test
• 437: bun 安定版、bun canary、bun PR #43662、bun test

試験コード

リンクはすべてコミット 5b9f56b を指すので、行番号はずれない。

• conhost.exe で新しい窓を起こし、終わるまで待つ（new-console.ts の 49〜78 行）。ケースごとに、パスを %~dp0 からの相対にした ASCII だけのバッチを書く
• 日時と pid を除いてログをまとめる（new-console.ts の 80〜102 行）と、各ケースの最後に流す共通の後始末（104〜113 行）
• 各ランタイムの中からコードページを読む（console.ts の 20〜47 行）。bun:ffi ・ koffi ・ Deno.dlopen で、読むだけ
• 送り手（emit.ts）、受け手（sink.ts。書き方を選べるようにした commit 86007f8 の版）、中継役（hold.ts）
• ReadConsoleOutputCharacterW で画面を読む（probe.ts の 17〜51 行）
• 画面 ・ コードページ ・ バイト列の判定（judge.ts の 7〜63 行）
• 隣のプロセス役: 932 用（neighbor-932.cmd）と 437 用（neighbor-437.cmd）