CLI: plugin startup git sync can trigger SSH/passphrase prompts on the TTY and corrupt Ghostty input when Git rewrites HTTPS GitHub URLs to SSH

What version of Codex CLI is running?

0.120.0

Regression starts at 0.117.0.
0.116.0 and earlier do not reproduce this issue in the same environment.

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux x86_64
Arch Linux / Omarchy

What terminal emulator and version are you using (if applicable)?

Ghostty 1.3.1
No tmux / screen / zellij involved

What issue are you seeing?

Since upgrading from 0.116.0 to 0.117.0+, launching codex can trigger an SSH key passphrase prompt immediately at startup.

Observed behavior:

1. I run codex
2. Codex starts its TUI
3. I see a prompt like:

Enter passphrase for key '/home/<redacted>/.ssh/id_ed25519_github':

1. Codex does not appear to properly wait for interactive input there and continues booting the TUI
2. After that, keyboard input in the chat composer is corrupted:

• normal typing inserts raw / broken characters
• Ctrl+C does not work
• I cannot exit cleanly
• I usually have to close the terminal tab entirely

This reproduces consistently on newer versions, and disappears immediately when I reinstall 0.116.0.

The broken input looks consistent with terminal keyboard enhancement / CSI-u style sequences being left active or the TTY state being interfered with by an unexpected interactive subprocess during startup.

What steps can reproduce the bug?

The issue appears to require all of the following:

1. Use Codex CLI 0.117.0 or newer
2. Use Ghostty
3. Have plugins enabled
4. Have a Git config that rewrites https://github.com/... URLs to SSH, for example:

[url "git@github.com:"]
    insteadOf = https://github.com/

1. Launch codex

On my machine, this causes Codex startup to attempt Git access for the curated plugin sync using a GitHub URL that is written as HTTPS in source, but rewritten to SSH by Git config. That in turn causes SSH/passphrase prompting on the controlling TTY while the TUI has already entered raw mode / enhanced keyboard mode.

A likely minimal repro setup is:

git config --global url."git@github.com:".insteadOf https://github.com/
codex

provided plugins are enabled and the SSH key requires a passphrase / interactive auth.

What is the expected behavior?

Codex startup background tasks should never prompt interactively on the TTY once the TUI has taken control of the terminal.

Expected behavior:

• startup plugin sync should be non-interactive
• if Git ends up requiring auth, it should fail fast
• Codex should fall back cleanly to its HTTP path
• the TUI should remain usable
• terminal input state should never become corrupted

Additional information

I investigated the regression locally in the open-source repo and found a strong candidate root cause.

Why this looks like a 0.117.0 regression

0.116.0 used HTTP/zipball sync for the curated plugins repo.

0.117.0 introduced a Git-first startup sync path for the curated plugin catalog, and only falls back to HTTP afterwards.

In current source, the startup sync performs Git operations against:

https://github.com/openai/plugins.git

via:

• git ls-remote
• git clone

in codex-rs/core/src/plugins/startup_sync.rs

However, Git URL rewriting still applies, so in environments with:

[url "git@github.com:"]
    insteadOf = https://github.com/

those commands become SSH-based and may prompt for a passphrase.

Why the TTY gets corrupted

The TUI enables raw mode and keyboard enhancement flags very early during startup. If a background Git/SSH subprocess then prompts on the controlling TTY, that interaction seems to interfere with terminal input state. In Ghostty this shows up as broken raw ...u-style keyboard sequences / unusable input.

This feels related in shape to other terminal-state / Ghostty input corruption reports, but here the trigger appears to be the plugin startup Git sync becoming interactive unexpectedly.

Local evidence

My Git config contains:

[url "git@github.com:"]
    insteadOf = https://github.com/

Codex logs on my machine show the curated plugin sync already hitting the SSH-rewritten path, for example failures like:

git ls-remote curated plugins repo failed ... git@github.com: Permission denied (publickey)

which strongly suggests the GitHub HTTPS URL is being rewritten to SSH during startup sync.

Proposed fix direction

I think the startup Git sync should be forced non-interactive, so that it can never steal the TTY from the TUI. For example, the Git subprocess wrapper used by curated plugin sync could set environment such as:

• GIT_TERMINAL_PROMPT=0
• GCM_INTERACTIVE=never
• GIT_SSH_COMMAND=ssh -oBatchMode=yes

That would make SSH/auth failures fail fast and preserve the existing HTTP fallback path, instead of prompting on the terminal.

I validated this approach locally with a small targeted patch and a focused test around startup_sync, and it appears to address the issue without changing the intended fallback behavior.

If this direction aligns with the intended fix, I'd be happy to help with additional repro details, logs, or a proposed patch if invited.