Key points

1. Bun switches the console to code page 65001 at startup, and restores the value it saved at exit. The code page belongs to the console and is shared by every process attached to it. Source: init() (output.rs lines 561 to 567) and restore() (output.rs lines 517 to 524). Evidence, the code page while Bun runs: 932 / 437 (T1)
2. Two Bun processes in one console overwrite each other's saved value. Output is garbled, 65001 is left on the console, and other programs in the same console break. Evidence: garbled screen 932 / 437 (T5), broken neighbor 932 / 437 (T4), forced kill 932 / 437 (T3)
3. PR #43662, the open fix for bun#43660, does not remove the cause. It fixes console.log output, but Bun still switches the console to 65001 while it runs (932 / 437), a forced kill still leaves 65001 (932 / 437), fs.writeSync(1), fs.write(1) and Bun.write(Bun.stdout) are still garbled (932 / 437), and restoring still loses a race now and then when the order is not fixed (timeline)
4. Node.js and Deno never change the code page and print correctly in every case: Node.js 932 / 437, Deno 932 / 437 (T1)

Request (bun#44693): do not change the console code page at all, and write all console output with WriteConsoleW. Every verdict was the same whether the console started at 932 (Japanese Windows) or 437 (English Windows). The details follow in Conclusion; how the tests were run is in Conditions.

Conclusion

Bun switches the console input and output code pages to 65001 the moment it starts (before any script code runs), and on exit restores "the value it saved at start". This alone causes every harm H1 to H7 in the plan. Node.js and Deno never changed the code page and behaved correctly in every case.

The rows are in order of importance: the harms that remain even with PR #43662 come first.

PR #43662 (the open fix for bun#43660)

PR #43662 writes console output with WriteConsoleW through bun_sys::write, and at exit restores a code page only if the saved value is not 65001. Its Windows x64 CI build was run through the same suite. It fixes what bun#43660 reported, but it keeps switching the console to 65001 at startup, so the harms that come from changing shared state remain:

• While Bun runs, the console is at 65001 for every process attached to it (T1)
• A forced kill still leaves 65001 behind, and a script run afterwards in the same console is misread (T3)
• fs.writeSync(1), fs.write(1) and Bun.write(Bun.stdout) still write with WriteFile, so in the ww order their output is garbled (T5), as the PR description and its review say
• Restoring "only a code page this process changed" still loses a race: after both processes exit, either the input or the output code page alone stays at 65001. How often this happens changes a lot from series to series: 0 times in 120 runs, 3 times in 60. See the timeline, which also derives the order from the PR's source
• Commit 6b5271c, pushed to the PR on 2026-10-16 (JST), skips SetConsoleOutputCP and SetConsoleCP at startup when the console is already at 65001. A console at 437 or 932 is still switched to 65001, so the results in this document were measured on the build before this commit, and the request in bun#44693 is not met by it. We re-ran the full set at 932 and 437 on the build with this commit (head commit 6b5271cb1): the verdicts for the PR build did not differ from those of 576eb251a in a single case. The runs with no fixed order (asis) printed correctly and restored the code page in all 60 runs at each of 932 and 437. The harms that remain after the PR, such as 65001 staying after a forced kill, are unchanged

The data flowing through the pipe itself was never corrupted, in any combination (T2). Every harm comes from rewriting shared state: the code page of the console. The stable and canary builds gave the same verdicts in every fixed case (T6), and every fixed verdict was the same at 932 and 437.

Related PRs

Named in robobun's reply on PR #43662. Both were open and not merged on 2026-10-10.

• PR #38140 (robobun, "ready for a maintainer"): reads console stdin with ReadConsoleW instead of ReadFile. Today the REPL, prompt(), alert(), confirm(), bun init, bun update -i and bun - read the console through ReadFile, which converts input with the console input code page, and on the Windows 10 / Server 2019 conhost the 65001 conversion breaks non-ASCII input. process.stdin, Bun.stdin and fs.readSync(0) go through libuv and are not affected. robobun says this PR must come before Bun can stop setting 65001 at startup, because the input side currently depends on it. The PR itself says "the ANSI conversion is the broken piece, not the code page"
• PR #42819 (dylan-conway): removes libuv on Windows and gives Bun its own event loop on an I/O completion port; pipes, the console and files move to src/io/windows/. robobun says that after it, the write hooks for fs.writeSync, fs.write and Bun.write can go into src/sys/windows/fs.rs::write_at and cover them all. Its list of fixed bugs includes "process.stdout.write was garbled once another process restored the code page (console.log still is)", which matches the harm measured here

Where in Bun's source

• init() (output.rs lines 561 to 567) saves GetConsoleOutputCP / GetConsoleCP and calls SetConsoleOutputCP(65001) / SetConsoleCP(65001)
• restore() (output.rs lines 517 to 524) puts the saved values back at exit
• The source comment already says restoration "may not be applied if the process is killed abruptly" (H6)

The links point to the current main. The timeline in T5 matches this code exactly: each process saves the value it sees at start, so the second process saves 65001.

T1. Code page over time

A single process runs in the console and prints abc 東京大阪 xyz. Values are input/output.

Test code: T1 (codepage.test.ts lines 35 to 51)

• Bun has already switched to 65001 when the first line of the script runs. It does so even if nothing is written to the screen
• Node.js and Deno stayed at the starting code page and printed Japanese correctly. This shows correct output does not require changing the code page
• With a single process, Bun puts the starting value back on exit, so the problem stays hidden

T2. Pipe combinations

The writer and the reader start together, and the reader writes the received bytes to a file. Each cell is "bytes, code page after exit", for a console started at 932 and at 437.

Test code: T2 (codepage.test.ts lines 53 to 81)

The command for each launcher is built here: lines 58 to 61

• The bytes flowing through the pipe were never corrupted, in any combination
• Connecting two Bun processes directly from cmd or pwsh 7 left 65001 behind (H3). If either side is Node.js or Deno, it is not left. This matches "it does not happen if either side is Node.js" in bun#43660
• Windows PowerShell 5.1 replaces the Japanese with ? in every combination (also for node | node; it is 5.1's own behavior). In the 5.1 column, the same bytes as node | node count as ✅. With 5.1 in between, 65001 was not left, because 5.1 does not run the two Bun processes at the same time. Running the same pipe through 5.1 20 times with the watcher, the reader started only after the writer had exited, in all 20 runs (11 to 22 ms later; watch.ndjson of run 1, results.jsonl). With no overlap, neither process can save the other's 65001

T3, T4. Forced kill and neighboring processes

T3. Forced kill

A single process that has written to the screen and is waiting is stopped with taskkill /F.

Test code: T3 (codepage.test.ts lines 83 to 102)

Because Bun restores the code page on exit, a forced kill leaves 65001 behind (H6). A cmd script that runs in the same console afterwards misreads its own source as UTF-8 and is garbled (H4).

T4. After a normal exit

The console after bun | bun exits normally (the lifetimes overlap and the writer exits first).

Test code: T4 (codepage.test.ts lines 104 to 121)

The screen with Bun, at 932 and at 437:

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

The same with Node.js, at 932 and at 437:

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

現在のコード ページ is the Japanese form of Active code page; on Japanese Windows it switches to English when the output code page is 65001. With both Bun builds, even without a forced kill, the neighbor script and chcp in the same console were affected (H4).

T5. Reproduction with fixed ordering

The second process starts about one second later, and the exit order is decided by delays. The two lifetimes always overlap. Each combination runs three times. Cells are "screen or bytes ／ starting code page after exit", for a console started at 932 and at 437. The prediction for each order is in T5 of the plan: ww garbled with 65001 left, wr and rw correct, rr correct with 65001 left.

Test code: T5 (codepage.test.ts lines 123 to 210)

For Bun 1.4.3 and canary, every combination matched the prediction of the plan, and all three runs were identical, at both 932 and 437. Once the order is fixed, the result is fixed. The build of PR #43662 was correct in every order when the reader writes with process.stdout, but the last three rows, where the reader writes the same text with fs.writeSync(1), fs.write(1) or Bun.write(Bun.stdout), are garbled on every build: those APIs still use WriteFile. These rows run with Bun builds only (Bun.write exists only in Bun).

Timeline of the garbling order (Bun 1.4.3, ww, screen, 932)

From this log. Values are input/output. w is the writer, r the reader, probe the observer Node.js process. The run at 437 gives the same picture with 437 in place of 932 (log).

   0ms probe  before          932/932
  45ms w      after start     65001/65001   ← the writer saves 932 and sets 65001
  47ms w      before writing  65001/65001
1093ms r      after start     65001/65001   ← the reader saves 65001 as the "original" value
2050ms w      before exit     65001/65001   → the writer exits and restores the saved 932
2854ms r      before writing  932/932       ← the reader writes UTF-8 bytes to a 932 console (garbled)
2860ms r      before exit     932/932       → the reader exits and restores the saved 65001
2989ms probe  after           65001/65001   ← 65001 is left behind

• The reader wrote raw UTF-8 bytes while the console was at 932. Had it passed the text to WriteConsoleW, it would have printed correctly whatever the code page (Node.js and Deno print correctly at 932 and 437)
• In relay, the Node.js process in the middle changes nothing. Overlapping lifetimes of the two Bun processes are enough for the same thing to happen (H7)

T5. Same shape as bun#43660

The same shape as bun#43660: both processes start together, with no fixed order, ten times (60 times for the build of PR #43662). The text is abc 東京大阪 xyz, passed with \u escapes (deno eval for Deno).

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

Test code: same shape as bun#43660 (codepage.test.ts lines 140 to 161)

• With the same command, Bun's result changed from run to run (H2), and the number of garbled runs also changed from run to run. It is decided by which of the two processes starts and exits first, and that order varies with OS scheduling
• The garbling reported in bun#43660 was the garbled side of this variation
• The build of PR #43662 printed correctly in all 120 runs and restored the code page every time. On another day, though, it left the output code page at 65001 in 1 of 20 runs (run 6 on 2026-10-07). See the timeline below
• The build of head commit 6b5271cb1 was run with no fixed order 300 times each at 932 and 437, with the watcher attached. It was also run 300 times each with the CPU filled by 8 busy-loop processes. All 1,200 runs printed correctly and restored the code page every time. Evidence: 932 (no load), 932 (load), 437 (no load), 437 (load)
• That the load widens the window was checked by running the earlier build (576eb251a) 100 times at 932 under the same load. It failed to restore the code page 3 times (runs 21, 70 and 92; evidence). Under the same load 6b5271cb1 had 0 failures in 600 runs. If its failure rate were still the earlier build's 3%, the chance of 600 straight successes would be about 1 in 80 million. This test can find a lost race, so the absence of failures is not luck. What was tested is only this shape (bun | bun), though, and it is not a proof for every order

Timeline of every process on the console (PR #43662)

To see which processes were on the console when the code page was left changed, the same command was run 60 more times with the build of PR #43662, starting at 932. A Node.js watcher was attached to the same console the whole time. It polled GetConsoleProcessList, GetConsoleCP and GetConsoleOutputCP continuously and logged every attach, every detach and every code page change with a UTC time (watch.ndjson). Node.js does not change the code page (T1).

The same shape was run several times, with and without the watcher. How often the code page was not restored changes a lot from day to day. Every series is listed, including those where it never happened.

Starting at 437 left the code page behind in the same way. Both times it was the input side, the same shape as runs 45 and 51 of 2026-10-10.

Run 9 on 2026-10-11 had the same shape as run 19 below: R started 7 ms after W set 65001, and after exit the console was left at input 932, output 65001. What follows analyzes the 60 runs of 2026-10-10.

The other 57 runs returned to 932 / 932 (results.jsonl, environment.json). The three runs, the bun lines only (UTC). W is the writer bun -e "console.log(...)" and R is the reader 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)

• No third process started while the console was at 65001. The code page was left changed with only the two bun processes
• In all three runs, the second bun started 8 to 11 ms after the first one had set 65001, so their lifetimes overlapped
• Both directions can be left behind: the output code page (run 19) or the input code page (runs 45 and 51)
• The watcher samples every few ms, so very short changes may be missing from the log

The order, derived from the PR's source

The tested build is the PR's head commit 576eb251a. Its output.rs is the only place that changes the code page:

• init() (output.rs lines 581 to 585) runs four separate calls: save the output code page, set it to 65001, save the input code page, set it to 65001
• restore() (output.rs lines 536 to 544) sets the output and then the input back to the saved value, but skips a side whose saved value is 65001

With only W and R calling these, each final state has a single order that produces it:

• Input left at 65001 (runs 45, 51): the last input change must be a set to 65001 that nobody undoes. W saved 932, so W's restore sets the input to 932. Only R's "set input to 65001" can come after that, and R must not restore it, so R saved 65001. The order is: R saves the input (65001) → W exits and restores the input to 932 → R sets the input to 65001. W's restore fell between R's save and R's set
• Output left at 65001 (run 19): the same order on the output side: R saves the output (65001) → W restores the output to 932 → R sets it to 65001. The input then came back, because R saved the input after W had restored it (932), and R's restore set it back at .263
• In every case the cause is the same: R's save and set are not one step, and W's restore lands between them. R then saves 65001 as its "original", and the PR's check skips restoring a saved 65001

Up to here this is a deduction from the source and the timestamps: the watcher does not see which process made each call, and the step between R's save and R's set is shorter than its sampling interval (in run 19 the output going to 932 and back is not in the log). So the next step recorded each call.

Per-call trace

W and R each ran under cdb (WinDbg 1.2610), with breakpoints on GetConsoleOutputCP, SetConsoleOutputCP, GetConsoleCP and SetConsoleCP in kernelbase. Each hit recorded the process, the value (the argument of Set, the return value of Get) and the caller address, then continued (trace-writer.ndjson, trace-reader.ndjson). The watcher ran as well. Of 40 runs from 932, 3 left the output code page at 65001.

Run 6 (UTC). W is pid 30744, R is 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)

• The trace shows exactly the order derived above: R saves the output (65001) → W restores the output to 932 → R sets the output to 65001. R's restore sets back only the input and skips the output, whose saved value is 65001
• The watcher agrees (output 932 at .531, back to 65001 at .533)
• W and R called from the same addresses: the four save-and-set calls from …989ceb, …989cfc, …989d01, …989d12, the output restore from …989b72 and the input restore from …975511. Both processes go through the same init and the same restore
• In all 3 runs that left 65001, R's GetConsoleOutputCP returned 65001 and R did not restore the output. In 14 of the 37 runs that came back, one process had also saved the other's 65001, but the other's restore came later, so the code page came back

The debugger stops bun at every call, so the rate of lost races cannot be compared with runs without it. Each of the two debuggers records its own times, so the order between the two processes can be off by a few ms (in run 21, going by the recorded times alone, R saved after W's restore). The values (what each process saved) are not affected by this. The debugger prints its banner before the script hides its output, so W's banner goes into the pipe and R prints it on the screen (screen.json).

Evidence (run 6): trace-writer.ndjson, trace-reader.ndjson, watch.ndjson. All 40 runs: results.jsonl. Code: tools/50_run/asis-timeline.ts --trace, tools/50_run/cdb-trace.js, summary by tools/50_run/summarize-trace.ts

Code: the watcher (watch.ts) and the runner (asis-timeline.ts)

Conditions

How results are judged

• Code page: each process reads GetConsoleCP / GetConsoleOutputCP right after start, right before writing and right before exit. Before and after each case, an observer Node.js process reads them (T1 shows that Node.js does not change the code page)
• Screen: the observer reads the characters on the console with ReadConsoleOutputCharacterW. Nobody has to look at the screen
• Neighboring processes: at the end of each case, chcp and a neighbor cmd script run in the same console. The script is saved in the starting code page (Shift_JIS neighbor: 東京大阪 for 932, CP437 neighbor: café for 437)
• Bytes: the reader writes the received bytes unchanged to a file, which is checked for correct UTF-8

✅ as expected (same as the expected behavior) / ❌ not as expected. Every ✅ and ❌ in the tables below is a link to the evidence file of that case: the screen (screen.json), the log with the code pages (log.jsonl) or the received bytes (out.bin).

Evidence

All files are in research/evidence/, one folder per case: cp<code page>/<bun or bun-canary>/<runner>/<case>/. Each case folder holds the batch file it ran (run.cmd), the log, the screen and, if any, the received bytes. The logs hold no date and no pid, so two runs can be compared with diff. The run time and the tool versions are only in the environment.json of each pass:

• 932: Bun stable, Bun canary, Bun PR #43662, bun test
• 437: Bun stable, Bun canary, Bun PR #43662, bun test

Test code

All links point to commit 5b9f56b, so the line numbers do not move.

• Creating a new console with conhost.exe and waiting for it (new-console.ts lines 49 to 78). Each case is written as an ASCII-only batch file whose paths are relative to %~dp0
• Merging the logs without date and pid (new-console.ts lines 80 to 102) and the common tail of every case (lines 104 to 113)
• Reading the code page from inside each runtime (console.ts lines 20 to 47): bun:ffi, koffi and Deno.dlopen, read only
• The writer (emit.ts), the reader (sink.ts, at commit 86007f8, which added the choice of write API) and the relay (hold.ts)
• Reading the screen with ReadConsoleOutputCharacterW (probe.ts lines 17 to 51)
• How the screen, code page and bytes are judged (judge.ts lines 7 to 63)
• The neighbor processes: for 932 (neighbor-932.cmd) and for 437 (neighbor-437.cmd)