Checked · 2026-10-20 · Three user reports on Japanese text and IME in Codex

Codex: Japanese shows as boxes, the first character goes missing, the IME deletes pasted text

As of 2026-10-20, GitHub has three separate reports about Japanese in Codex: 52500 – in the macOS desktop app, Japanese inside code sections appears as small boxes containing question marks in the sent user message and in assistant responses; 51909 – in the TUI of Codex CLI, the first character of a Japanese reply is sometimes not displayed; 53972 – on macOS, typing tte with the Japanese IME deletes text that was pasted earlier. The only official reply is the one under 51909, and it says that more information is needed to tell whether the character is missing from the response or only lost on display.

Updated 2026-10-20

One key for Claude, GPT and leading Chinese models, billed per token, up and running in minutes.

Billed per token — live rates on /models
Pay by card (Visa / Mastercard / AMEX), Apple Pay, Google Pay or crypto
Self-service: top up and activate instantly

Create account View pricing

#Japanese as boxes on the desktop#TUI: the first character is sometimes missing#IME deletes pasted text#The Codex team asks for more information

Symptom, environment and status of each report

Boxed question marks (closed by the reporter)

52500 · macOS desktop app

The report writes that Japanese is readable in the desktop composer, and that after sending, Japanese inside Markdown inline code and code blocks in the sent user-message bubble appears as small boxes containing question marks; the code sections of assistant responses show the same, while ordinary prose and italic JavaScript comments stay readable. Environment: desktop build 26.1007.21159 (build 20052), macOS 27.0 (26A428), Apple Silicon. The report itself says it only describes the rendering and that the root cause is unconfirmed. The report was submitted on 2026-10-09 and closed on 2026-10-10 by the reporter themselves; there are 0 comments under it, and no official reply and no note of a fix.

First character sometimes missing

51909 · Codex CLI TUI

The report writes: codex-cli 0.161.0, on macOS 26.6.2 (Darwin 25.6.0, arm64) with iTerm2, and the locale is LANG=ja_JP.UTF-8. The first character of a Japanese reply is sometimes not visible; the report captured an example with the initial character missing, while the surrounding text and the Worked for 1s footer render normally. The report writes that this is intermittent, that the trigger has not been isolated, and that it is not established whether the character is missing from the response itself or only from the terminal rendering.

IME deletes paste

53972 · macOS desktop app

The report writes: Codex App 26.1007.71326 (build 20398), macOS 26.6.2 (build 25G83). You paste a text, then type tte in the Japanese romaji input, and on the final e the earlier pasted text disappears, leaving only the word you were composing; this happens before you press Enter or space. It reproduces with Google Japanese Input and with the Japanese Romaji input built into macOS, and the same sequence does not cause the problem in Sublime Text.

The Codex team’s reply

The Codex team asks for more information

The Codex team’s reply (account etraut-openai, whose reply is marked "response from codex"; the account is flagged as CONTRIBUTOR on the issue) under 51909 says: more information is needed to tell whether the character is missing from the response or only lost on display; please run /feedback in an affected session, choose bug, attach the logs, and post the feedback ID or link that is shown back into the issue; the screenshot the reporter mentioned would also help, and if it happens again, please check whether the output of /copy or /export contains the missing character. As of 2026-10-20 the official side has not reached a conclusion.

Where things stand

There are three separate things here, each with its own status. 52500 is a report about boxed question marks: it was submitted on 2026-10-09, closed on 2026-10-10 by the reporter themselves, there are 0 comments under it and neither an official reply nor a note of a fix was left. 51909 is a report about the first character of a Japanese reply sometimes not being displayed on the Codex CLI screen: submitted on 2026-10-08, with 1 comment in which the Codex team asks for more information, and on 2026-10-20 it is still open. 53972 is a report about pasted text disappearing while a word is composed with the IME: submitted on 2026-10-14, with 2 comments from two other users: one adds that it reproduces on Windows 11 as well, the other that other doubled-consonant input such as kko triggers it too and that it does not reproduce in the Codex CLI. The official changelog for 0.163.0 (2026-10-15) has no entry about Japanese or input methods.

The official changelog as of 2026-10-20

The latest entry in the official Codex CLI changelog is 0.163.0 from 2026-10-15. Searching the text of that changelog turns up no Japanese, no IME and no input method entry, so as of 2026-10-20 the official changelog carries no fix for any of the three reports.

Three dates

2026-10-08

Report 51909 is filed: the report writes that the first character of a Japanese reply is sometimes not displayed under codex-cli, with the environment given in the 51909 item above; the reporter writes that it is intermittent and that the trigger has not been isolated.

2026-10-10

Report 52500 is closed on 2026-10-10 by the reporter themselves, with nothing under it and no official reply or note of a fix; on the same day the Codex team replies under 51909 and writes that more information is needed to tell whether the character is lost in the response or only on display.

2026-10-14

Report 53972 is filed: on macOS, typing tte with the Japanese IME makes the last e delete the text pasted earlier; the environment is Codex App 26.1007.71326 and macOS 26.6.2.

What the official side says and what it does not

Confirmed (word for word checkable)

52500: Japanese is readable in the composer and becomes boxes with question marks in the code sections after sending; submitted on 2026-10-09, closed on 2026-10-10 by the reporter themselves, 0 comments. 51909: the first character of a Japanese reply is sometimes not displayed on the Codex CLI screen; submitted on 2026-10-08, 1 comment, and that comment is the reply of the Codex team, which writes that more information is needed to tell whether the character is missing from the response or only lost on display, and asks for /feedback in an affected session with bug selected and the logs attached, the feedback ID or link to be posted back to the issue, and /copy or /export to be checked for the missing character. 53972: the pasted text disappears when the last e of tte is typed; submitted on 2026-10-14, 2 comments: the first user adds that it reproduces on Windows 11 with Google Japanese Input and does not reproduce with the built-in Microsoft IME; the second adds that doubled-consonant input such as kko triggers it too and that it does not reproduce in the Codex CLI.

What the official side has not said

No cause has been given. 52500 itself says it only describes the rendering and that the root cause is unconfirmed, and it was closed by the reporter without any note of what was fixed, so there is no way to tell whether the boxed question marks are gone. In 51909 the reporter has not isolated the trigger and does not know whether the character is missing from the response or lost on display; the /feedback logs and the feedback ID the Codex team asked for are not in the discussion as of 2026-10-20. The cause of 53972 is not public either, and the other user’s comparison only shows that the problem did not come back with a different input method. The official changelog has no entry for Japanese or input methods either.

What you see on screen and what disappears while you type

What you see on screen

52500 reports the boxed question marks: after sending, Japanese in the code sections of the sent message and of assistant responses appears as small boxes containing question marks, and the report describes this as a rendering symptom only, with the root cause unconfirmed. 51909 reports that the first character of a Japanese reply is sometimes not displayed on the Codex CLI screen; whether the character was never in the response or is only lost on display is not established in the report.

What disappears while you type

53972 reports the loss of pasted text while a word is composed with the IME: the pasted text is still in the box, but typing tte in romaji removes it on the last e and only the word you were composing remains. In the comments another user reproduces it on Windows 11 as well and does not reproduce it with the built-in Microsoft IME.

What you can do first

① Sort the three symptoms apart: the boxed question marks of 52500 are what you see on screen; the disappearing pasted text of 53972 happens while you type; for 51909, whether the first character was never in the response or is only lost on display is not established. ② To check whether the character is really in the response, copy the reply out with /copy in an affected session and see whether the character is missing – that is the check the Codex team asked the reporter to make. ③ Write down the environment: Codex version, system, terminal emulator, locale and which IME you use. ④ If you want the official side to follow up, do what the Codex team asked: run /feedback in an affected session, select bug, attach the logs and post the feedback ID or link that is shown back to the issue; if it happens again, check whether the output of /copy or /export contains the missing character. ⑤ For the IME case you can try a different IME as a comparison: on Windows 11 a user reports that it did not come back with the built-in Microsoft IME, which is a user report and not a solution published by the official side. ⑥ Keep an eye on the status of 52500: it was closed on 2026-10-10 by the reporter themselves, but nothing under it explains what was fixed, so do not read the closure as a solution.

Configuring Codex with a QCode key

One thing first: the three reports above are phenomena the reporters observed in their own environments, and neither the reports nor the official side has confirmed a cause. Configure it the way the QCode documentation for Codex writes it: in ~/.codex/config.toml put model_provider = "qcode", base_url = "https://api.qcode.cc/openai", wire_api = "responses" and requires_openai_auth = true, and put the key into ~/.codex/auth.json under "OPENAI_API_KEY" with a value that starts with cr_; on Windows both files live in %USERPROFILE%\.codex\. On the QCode side billing is per token, and the per-model rates are listed on /models.

Frequently asked questions

Are these the same problem?

No, they are three separate things, and the symptoms and environments differ as well.

What environments do the reports mention?

Three different ones. 52500: desktop build 26.1007.21159 (build 20052), macOS 27.0 (26A428), Apple Silicon. 51909: codex-cli 0.161.0, macOS 26.6.2 (Darwin 25.6.0, arm64), iTerm2, with the locale written as LANG=ja_JP.UTF-8. 53972: Codex App 26.1007.71326 (build 20398), macOS 26.6.2 (build 25G83).

Has the official side replied?

Yes, and there is exactly one official reply, under 51909: the Codex team writes that more information is needed to tell whether the character is missing from the response or only lost on display, and asks for /feedback in an affected session with bug selected and the logs attached, the feedback ID or link to be posted back into the issue, and, if it happens again, a check of whether the output of /copy or /export contains the missing character. 52500 has no official reply; it was closed on 2026-10-10 by the reporter themselves and there are 0 comments under it. Both comments on 53972 are other users adding reproduction details, not official replies. As of 2026-10-20 there is no official conclusion.

How do I tell whether the display is at fault or the reply is missing a character?

Copy the reply out with /copy and look at whether the character is really missing – that is the check the Codex team asked the reporter to make, and it is how the two cases can be told apart.

Does switching the input method fix it?

There is no confirmed method. On Windows 11 one user reports that it did not come back with the built-in Microsoft IME, which is his own comparison and not a solution published by the official side; on macOS the reporter reproduces it with both Google Japanese Input and Apple’s built-in Japanese Romaji input.

Which option should I pick in /feedback?

Choose bug, as the Codex team’s reply says. Under 51909 that reply asks you to run /feedback in an affected session, select bug, attach the logs and post the feedback ID or link that is shown back into the issue; it is a step in gathering evidence and does not mean the cause has been found.

Sources

User reports: three issues and their comments in the openai/codex repository on GitHub (checked 2026-10-20; 51909 submitted 2026-10-08, 52500 submitted 2026-10-09 and closed by the reporter on 2026-10-10, 53972 submitted 2026-10-14). Official wording: the official Codex CLI changelog on developers.openai.com (checked 2026-10-20; 0.163.0 released 2026-10-15). QCode side: the QCode documentation pages for Codex and for endpoints and API paths on docs.qcode.cc (checked 2026-10-20), and the Pay-as-you-go Packs page on qcode.cc in five languages (checked 2026-10-20).

Run Codex with a QCode key

Not ready for a monthly plan? Pay-as-you-go Packs start at $4 for a one-time quota you use within 7 to 90 days.

Create an account

Models and live rates View plans