Fixing Japanese Mojibake (Garbled Text) in Antigravity's Integrated Terminal

You open the integrated terminal in Antigravity, run git log --oneline, and your commit messages come back as something that looks like a cursed string: 譁?ュ怜喧縺代＠縺ｾ縺励◆. Or npm run start prints an error you can't read. Or you ls your app's asset folder and every Japanese filename has turned into a row of ? marks. I am Hirokawa, an indie developer hopping between Windows and macOS, and I have lost half a day to this exact symptom more than once — usually right after setting up a new Mac or switching to Git Bash for the first time.

Mojibake in the terminal is a dramatic-looking problem with a boring cause. In nearly every case, the shell is emitting bytes in one encoding and the terminal is interpreting them in another, and you only need to align two settings to fix it. Below are the patterns I see on Windows, macOS, and WSL2, including the specific traps I have stepped on while running four sites under Dolice Labs (including Antigravity Lab) where Japanese filenames and commit messages show up every day.

Step one: figure out where the corruption is happening

Before changing anything, isolate the layer. Is Antigravity at fault? The shell? The command's output itself?

Start by running the same command in a plain terminal that does not go through Antigravity — Terminal.app on macOS, or Windows Terminal or cmd.exe directly on Windows. If the text renders cleanly there, the problem is in Antigravity's integrated terminal settings. If it still breaks, the issue is in the shell or the data source.

Next, try a trivial echo: echo "テスト". If that breaks, you are almost certainly dealing with a font or encoding mismatch in the terminal pane. If echo works but git log breaks, the encoding of the commit messages themselves (or Git's core.quotePath) is the suspect.

Finally, pipe the broken output through od -c (on Unix) or Format-Hex (on PowerShell) to see the raw bytes. If you see three-byte sequences starting with E3 81 or similar, the data is already UTF-8 — your terminal is just decoding it as something else, which is the easiest case to fix.

Windows: 99% of the time it's CP932 vs UTF-8

Almost every case of Windows mojibake comes from the same mismatch: the command prompt defaults to code page 932 (Microsoft's Shift_JIS variant), while Node.js, Python, and Git for Windows emit UTF-8.

If Antigravity is launching PowerShell, run chcp in the integrated terminal. If it returns 932, you're in CP932 mode. Switching to UTF-8 with chcp 65001 works immediately, but it resets when you open a new terminal. For a permanent fix, drop this into your PowerShell profile:

# If $PROFILE doesn't exist, run: New-Item -Path $PROFILE -ItemType File -Force
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8
chcp 65001 | Out-Null

In Antigravity, pin Settings → Terminal → Integrated: Default Profile to PowerShell and add -NoLogo to the profile args so your profile script runs cleanly on every open.

For Git Bash users, append the following to ~/.bashrc or ~/.bash_profile. Setting both LANG and LC_ALL is the iron rule here. If you only set one, you end up with the very confusing situation where man and less break while everything else works.

export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8
export LESSCHARSET=utf-8

Git itself adds another trap. If git status shows Japanese filenames as octal escapes like "\343\201\202...", that is not mojibake — that is Git's quoting mode. A one-time git config --global core.quotePath false fixes it permanently, and from then on 素材/アイコン.png shows up as itself.

macOS: it's usually "no locale set" or an SSH gotcha

macOS defaults to UTF-8, so people assume it never breaks. I assumed that too — until I cleanly installed macOS on a new M3 MacBook Pro, SSH'd into a colocation server, and watched every Japanese character on the remote side become ? because LANG was unset there.

Run locale locally. If you see LANG=ja_JP.UTF-8 or LANG=en_US.UTF-8, you're fine. If LANG= is empty, add one line to ~/.zshrc:

export LANG=ja_JP.UTF-8

The classic SSH gotcha is that your local zsh is forwarding LC_* variables to a remote that doesn't have those locales installed. You fix it on whichever side you control — either comment out SendEnv LANG LC_* in /etc/ssh/ssh_config locally, or run sudo locale-gen ja_JP.UTF-8 on the remote. I pick the latter when the remote is an Ubuntu server I own, and the former when I'm dealing with a mixed corporate environment.

On the Antigravity side, leave Settings → Terminal → Integrated: Inherit Env at true. Flipping it to false means your .zshrc exports never reach the integrated terminal, which leads to the maddening situation where every other terminal works and only Antigravity breaks.

WSL2: Windows and Linux locales are tangled together

If you're using WSL2, the Windows terminal settings and the Linux locale settings are intertwined, so fixing only one side leaves you stuck. I run npm inside WSL2 a lot when working on Rork Lab content, and this has bitten me a few times.

First, check that the locale is generated on the Linux side: locale -a | grep ja. If ja_JP.utf8 doesn't appear, generate it:

sudo locale-gen ja_JP.UTF-8
sudo update-locale LANG=ja_JP.UTF-8

Then add export LANG=ja_JP.UTF-8 to ~/.bashrc (or ~/.zshrc), restart the shell, and confirm with echo $LANG.

If Antigravity's integrated terminal launches wsl.exe on the Windows side and the host code page is still 932, the Linux side will emit UTF-8 but the Windows-side host will misread it. The fix is exactly the PowerShell profile change covered earlier — put chcp 65001 and the UTF-8 OutputEncoding assignment into $PROFILE.

When none of the above works: three final checks

If you have done everything above and the output is still broken, here are the three places I always look next.

The first is the terminal font. If Antigravity's Settings → Terminal → Integrated: Font Family is set to a font without CJK glyphs (for example, plain Cascadia Code without a CJK fallback), the encoding is fine but the glyphs render as tofu boxes. Switching to HackGen Console NF, Cica, or a Nerd Font with Japanese support resolves it.

The second is the source file itself. Run file -i logs/error.log — if it reports charset=shift_jis, no terminal setting will save you. Read it with iconv -f shift_jis -t utf-8 logs/error.log | less, or convert in place with nkf --overwrite -w logs/error.log. As an indie developer who has been shipping Android apps since 2014 (with around 50 million cumulative downloads across the catalog), I still occasionally bump into Shift_JIS log files left over from the Eclipse era, and this trick has rescued me more than once.

The third is Antigravity itself, restarted with extensions disabled. Settings Sync sometimes pulls in a terminal-related extension from another machine that quietly overrides LANG. Open Help → Toggle Developer Tools, switch to the Console, and run process.env.LANG to see what the integrated terminal actually receives. If it doesn't match what your shell exports, an extension is the culprit.

A checklist for keeping a fresh machine mojibake-free

The most expensive part of this problem is the time it eats when you're trying to ship. Here is the short checklist I run through whenever I install Antigravity on a new machine, so that Japanese commit messages and filenames never become an emergency later.

1. Consolidate LANG=ja_JP.UTF-8 and the UTF-8 exports in your shell profile (.zshrc / .bashrc / $PROFILE).
2. On Windows, put chcp 65001 and the UTF-8 OutputEncoding lines into your PowerShell profile.
3. Run git config --global core.quotePath false once.
4. Pin Antigravity's Font Family to a CJK-capable font.
5. If you use Settings Sync, double-check that terminal settings from another machine haven't silently overwritten yours.

The five minutes you spend on these settings before opening a project save you the half-day I lost finding out the hard way. Thanks for reading — I hope it saves you the same half-day.