TTY echo breaks after interactive sudo prompt; requires killing Codex CLI

I experience a similar issue. I'm currently using Codex to troubleshoot some bluetooth problems on my Linux machine, and it tries to run some sudo commands to probe the system. When those are executed, Codex would wait for me to input the passwords. However, if the passwords contain special characters, I can see those characters printed on the screen instead of being hidden, and the final command failed due to a password error.

just ask model to only use sudo in non-interactive way. its working like that for me.

We eliminated broken sudo prompts under Codex CLI by funneling all privileged actions into pkexec self-elevating scripts (with preflight checks + a generic wrapper). This keeps authentication out of the TTY path entirely and avoids raw-mode input issues.

# ---- self-elevate header (put at very top of your script) ----
if [[ ${EUID:-$(id -u)} -ne 0 ]]; then
  exec pkexec /bin/bash "$(readlink -f "$0")" "$@"
fi
# --------------------------------------------------------------

If maintainers are open to it, I’m happy to contribute a short docs blurb (“GUI elevation on Linux via pkexec”) and a sample script in examples/.

EDIT: I created a gist with examples:
https://gist.github.com/sstavar/d273b6e4a8323b045c2f5b2c95b45c21

We’re seeing the exact same failure mode on Codex CLI 0.45.0 (gpt‑5 high, Linux host). Any time a
workflow drifts into an interactive sudo prompt the agent’s shell goes sideways:

• Echo shuts off, keystrokes lag or appear in bursts, Ctrl‑C/Ctrl‑D barely registers.
• codex resume or codex resume --last eventually gets the shell back, but the entire turn that hit the

prompt is gone, so you lose whatever context/output was being built.

Given how often infrastructure work touches privileged actions, we ended up hardening our own scripts
so Codex never reaches a raw prompt:

1. Detect non-interactive shells

We added a guard that checks for CI, lack of a TTY, or a custom LACARD_NON_INTERACTIVE flag.
If we’re in that mode the code refuses to run sudo -v and prints:
“Cannot refresh sudo credentials in non-interactive mode. Run ‘sudo -v’ manually before invoking
this command.”
That stops the hang before it starts, and the user can refresh credentials out-of-band.

1. Wrap every sudo call with a helper

Instead of sprinkling sudo around, we centralised on a helper:

Every privileged command (apt-get, tee, systemctl, etc.) goes through this helper, so by default it runs sudo -n. If the human really wants an interactive prompt they export ALLOW_INTERACTIVE_SUDO=1 before launching Codex.

     def with_sudo(args):
         if not needs_sudo():
             return args
         sudo = shutil.which("sudo")
         if not sudo:
             return args
         cmd = [sudo]
         if os.environ.get("ALLOW_INTERACTIVE_SUDO") != "1":
             cmd.append("-n")
         return cmd + list(args)

1. Add quick checks

We dropped an inexpensive pytest that scans our source tree for raw sudo usage outside a short
allowlist. It’s crude but keeps new code from regressing back to direct prompts.

1. Doc the workflow

The guidance we give teammates/hobbyists using Codex is:

• Run sudo -v manually before starting a session.
• Ask the agent to “only run sudo in non-interactive mode” (echoing what a previous commenter

suggested).

• If the agent insists on an interactive flow, have it print the command instead so you can copy/

paste it in your own shell.

• If the terminal is already jammed: restarting Codex will usually restore

echo, but expect to lose whatever context was in that turn.

With those guardrails we haven’t seen the locked terminal or mangled input since. It would still be
great if Codex itself detected when a command switches the TTY into raw mode and surfaced a warning
or an approval step—anything that prevents context loss and the “invisible password prompt” confusion
would be a big win.

Hey @ehallick or @SarahLacard, can you share the thread-id of a session if you're still seeing this issue? You can get the thread-id via the /feedback command in the CLI. Thanks

Tested briefly and did not see the same error, esc was able to interrupt the agent - sudo is still blocking and prints the prompt to the user in the input area, however on relaunch, the agent context was still missing. No lag appeared during sudo, but this was in a conversation only a few messages long.

thread ID 019b062b-cb40-76b2-ad59-f3fb78ef9836

Following up on this: https://github.com/openai/codex/issues/3646#issuecomment-3635147369

In the most recent update of Codex, v0.66.0, I'm also seeing agent context disapear when returning to a previous message with the esc hotkey, and I've encountered this bug twice in the last hours, losing critical agent context for the prompt I returned to in order to edit. I can not purposefully replicate in a new session, through restart or returning to a previous message. Unsure if related to the sudo bug, it was not encountered during the bug in question, but the same issue, missing context was present.

This bug report is very stale at this point. It hasn't received any upvotes or additional responses in four months. If you're seeing a similar behavior, please use /feedback to open a new bug report and include the thread ID.