Windows: visible console windows flash for shell process children on every session/turn

What version of Codex CLI is running?

codex-cli 0.157.1

What subscription do you have?

Plus

Which model were you using?

No response

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Windows Terminal + Powershell

Codex doctor report

What issue are you seeing?

On Windows, a batch of visible console windows flashes for git.exe / pwsh.exe (and other helper) child processes:

several git.exe windows on every new session, and again on every turn;
pwsh.exe windows for shell/exec child processes.

What steps can reproduce the bug?

On Windows, run codex interactively (e.g. in Windows Terminal) on a project inside a git repository (default config, no --no-daemon).
Start a new thread and send a turn.
Observe console windows flashing for git.exe (session start + every turn) and pwsh.exe (shell/exec helpers).

Workaround that confirms the diagnosis: codex --no-daemon runs the session embedded in the TUI process (console attached), and the flashing stops.

What is the expected behavior?

No visible console windows. Helper subprocesses spawned by the console-less daemon backend should either inherit a hidden console or be created with CREATE_NO_WINDOW.

Additional information

Source analysis at tag rust-v0.157.1:

Why the spawning process has no console:

codex-rs/features/src/lib.rs:941-944 — daemon_auto_start is enabled by default.
codex-rs/tui/src/startup_orchestration.rs:494-544 — TUI auto-starts the shared daemon and targets AppServerTarget::LocalDaemon (session runs in the daemon's app-server backend, not in the TUI).
codex-rs/app-server-daemon/src/backend/pid_start.rs:209 — backend spawn uses DETACHED_PROCESS | CREATE_BREAKAWAY_FROM_JOB → no console. spawn_without_inheriting_stdio (backend/windows.rs:56+) only clears stdio handle inheritance and adds no window suppression.

Unsuppressed child spawns from that console-less backend:

git.exe (dominant source): codex-rs/git-utils/src/git_process.rs:47-63 goes through JobObject::spawn_contained, and codex-rs/utils/pty/src/win/job.rs:125-127 only sets CREATE_SUSPENDED (no CREATE_NO_WINDOW); the fallback path resets creation_flags(0). Volume: new session → codex-rs/rollout/src/recorder.rs:1977-1978 → collect_git_info (git-utils/src/info.rs:66-82) = 4 spawns; every turn → codex-rs/core/src/turn_metadata.rs:547-551 = 3 more (plus a possible fsmonitor probe). Direct Command::new("git") sites in git-utils (apply.rs / baseline.rs / branch.rs / operations.rs) share the gap.
pwsh.exe / shell helpers: codex-rs/exec-server/src/fs_sandbox.rs:516, codex-rs/exec-server/src/shell_snapshot.rs:287, codex-rs/windows-sandbox-rs/src/unified_exec/backends/legacy.rs:118 (ConsoleMode::Inherit, mapped to flags 0 in process.rs:109-113; default WindowsSandboxLevel::Disabled takes this path), codex-rs/hooks/src/engine/command_runner.rs:233-245, codex-rs/hooks/src/legacy_notify.rs:53-66, codex-rs/cli/src/desktop_app/windows.rs:34-56.
The codebase already sets CREATE_NO_WINDOW correctly elsewhere (e.g. bin/command_runner/win.rs:351, rmcp-client/src/stdio_server_launcher.rs:297), so this looks like an omission.
Checked against current main (e72da2b, 2026-09-26): git_process.rs, job.rs, legacy.rs, pid_start.rs are unchanged vs 0.157.1 — upgrading does not fix this.

Suggested fix:

Minimal: in codex-rs/app-server-daemon/src/backend/pid_start.rs:209, replace DETACHED_PROCESS with CREATE_NO_WINDOW (keeps the backend detached from the launching terminal and breakaway-safe, but gives it a hidden console that children inherit — removes the flashing for all daemon-managed backends in one line).
Robust: also set CREATE_NO_WINDOW at the individual spawn sites above (git_process / job.rs, unified_exec legacy backend + (None, NoWindow) mapping in process.rs:109-113, exec-server spawns, hooks, desktop_app powershell) so any console-less parent is covered.

This issue is written by codex and review by human.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows CLI 0.157.1: Plain text messages trigger background Git queries and flashing terminal windows (--no-daemon avoids this) #48356
Windows: background Git checks open Terminal windows at turn start (fix commit) #48029
[Windows][Codex CLI 0.157.0] Terminal windows repeatedly pop up during normal use #48059
Windows: terminal windows repeatedly flash during requests after installing the Codex daemon #48074

Powered by Codex Action

i saw that v0.157.1 changelog claims it was fixed, but apparently it wasn't.
so i think it's necessary to create a new issue for it.

A commit from last night indicated a fix, but testing showed otherwise; the issue persists.

codex is unusable on Windows like this. console windows keep opening and stealing focus

Additional Windows 11 Home (build 26200) reproduction: Codex CLI 0.157.1 and its 0.157.1 managed app-server daemon were installed/running. Launching an older standalone CLI 0.156.1 without --no-daemon still produced brief PowerShell windows during tasks. Relaunching the same 0.156.1 executable with --no-daemon stopped the extra windows in the user's test. Read-only process inspection showed the 0.157.1 managed daemon with pwsh.exe, node.exe, node_repl.exe, and codex-code-mode-host.exe descendants; several had conhost.exe children. I did not capture a PID for each transient visible window. Thus downgrading the CLI executable alone did not resolve the symptom here, while bypassing the shared daemon did.

Additional independent reproduction from the Codex desktop app (not only the CLI):

Environment

Windows 11 Pro x64, build 10.0.26200
Codex desktop package: OpenAI.Codex_26.917.8451.0_x64
Managed app-server/CLI runtime: codex-cli 0.157.1
Native Windows sandbox: elevated
Default console host: Windows Terminal
The behavior began immediately after updating to 0.157.1.

Process evidence

While reproducing the issue, each shell/tool action created a matching group with the same start timestamp:

codex-command-runner-0.157.1.exe
pwsh.exe
conhost.exe

Four concurrent diagnostic shell calls produced four command-runner processes, four PowerShell processes, and four conhost.exe processes at the same timestamp. The visible flashes correlated directly with those groups.

PE subsystem inspection showed:

codex-command-runner-0.157.1.exe: Windows GUI subsystem
node_repl.exe: Windows Console subsystem
codex-computer-use.exe: Windows Console subsystem
daemon codex.exe: Windows Console subsystem

This suggests the GUI command runner is launching console-subsystem children such as pwsh.exe without consistently using CREATE_NO_WINDOW (or an equivalent hidden-console mechanism), causing Windows Terminal/conhost allocation.

There are also two additional desktop-app paths that can add flashes:

node_repl.exe is launched during session/plugin startup.
The desktop-managed top-level notify command invokes codex-computer-use.exe turn-ended, which can add another console flash when a turn finishes.

Configuration checks

No project-level Codex configuration was present.
No active custom/third-party hook was responsible.
The installed Warp plugin was disabled.
No matching Windows Application Error/crash event was found.

Expected behavior

All non-interactive helpers spawned by the desktop app or managed daemon should remain background-only and must not allocate visible Windows Terminal/conhost windows.

No private paths, command payloads, conversation content, credentials, or raw logs are included in this comment.

[features]
daemon_auto_start = false

Can alleviate this problem

Additional reproduction on Windows 10 build 19045 with Codex CLI 0.157.1 (npm install), Windows Terminal as the default terminal, and PowerShell 7.6.6:

With the shared app-server daemon auto-started, agent shell commands caused transient console windows to appear over the user's browser and steal keyboard focus. The windows closed too quickly to capture a screenshot.
Read-only process inspection showed the managed 0.157.1 app-server spawning pwsh.exe, cmd.exe, node.exe, node_repl.exe, and codex-code-mode-host.exe children, with corresponding conhost.exe / OpenConsole.exe activity. Creation times coincided with command execution. I cannot attribute each visible flash to one exact child PID.
We set [features] daemon_auto_start = false in the user's Codex config, stopped the existing daemon, then restarted Codex normally with plain codex. A harmless agent command (Get-Date) ran afterward, and the user confirmed that no console window appeared or stole focus.

Expected: background agent commands and helpers should not create foreground console windows. This is a serious usability regression because it interrupts typing in other applications. The config change is a workaround; users should not need to disable the shared daemon to avoid focus stealing.

No personal paths, raw logs, or conversation transcripts are included.

Additional reproduction with a more specific child/runtime configuration:

Windows 11 with Windows Terminal
Codex CLI 0.157.1
PowerShell 7.6.6 installed from the Microsoft Store; the child executable resolves to C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe\pwsh.exe
[windows] sandbox = "elevated"

Every non-interactive agent shell execution opens a new Windows Terminal tab or window. This is reproducible across commands and does not depend on the model response. The same workflow did not produce these tabs with the previously installed Codex CLI 0.153.4.

I also checked current main at 985cf47a4e. It includes #48483 (1a89aec960), which sets CREATE_NO_WINDOW in codex-rs/utils/pty and adds detached-process coverage, but the released 0.157.1 behavior remains reproducible. This suggests that the shared-wrapper fix does not yet cover every helper or daemon launch path.

Could the regression test matrix include the actual Microsoft Store pwsh.exe with [windows] sandbox = "elevated", and verify that no conhost.exe or Windows Terminal tab is created? The fix should apply CREATE_NO_WINDOW to every non-interactive child spawn while preserving CREATE_SUSPENDED and Job Object flags. daemon_auto_start = false or --no-daemon is a useful diagnostic workaround, but not an acceptable default for the managed daemon.

Confirmed on another Windows x64 installation running Codex 0.157.1: launching with codex --no-daemon mitigates the problem. After restarting in no-daemon mode, the repeated visible PowerShell/console flashes stopped during equivalent local tool activity. This supports the report's diagnosis that the regression is in the daemon-backed process-launch path.

Additional affected user on Windows with codex-cli 0.157.1 (codex --version verified). Since the recent update, short-lived black console windows repeatedly open and close while Codex is doing ordinary work. They steal keyboard focus, interrupt typing, and make the CLI effectively unusable. This happens repeatedly during a task, not only at startup.

Please prioritize a release that fully suppresses visible windows and focus stealing for non-interactive child processes, and verify it against the current Windows CLI behavior. I see that #48483 has been merged, but 0.157.1 still has this problem.

Additional instrumented reproduction from ChatGPT/Codex Desktop on Windows (2026-09-28):

Installed desktop package: OpenAI.Codex_26.924.2738.0_x64. Its app-server log resolved codex.exe from an override to a globally installed npm codex-cli 0.157.1 (source=override; CODEX_CLI_PATH is the selected browser-use path). The package also contains 0.158.0-alpha.2.1, but I have not tested that bundled binary as a workaround.
A read-only process-start monitor (300 ms sampling) captured two single-flash events on turn activity: codex.exe -> pwsh.exe -> conhost.exe at 11:02:54 and 11:03:06 local time, with OpenConsole.exe starting in the same second. The user observed a brief PowerShell 7 window.
Separate rapid-flash events captured four git.exe children directly under the same Codex app-server in each burst at 10:55:20–23 and 10:58:37, with corresponding conhost.exe / OpenConsole.exe starts. The user observed Git terminal windows opening and closing rapidly. This is intermittent across prompt submissions.
An independent 30-second PowerShell poll on this machine was traced to ASUS ArmouryDevice (asus_framework.exe) and is excluded from the Codex events above.

The process parentage and timestamps are confirmed locally; the transient visible windows are the user's observation. I did not capture a window-handle-to-PID match, individual Git arguments/exit codes, or an A/B run with another Codex runtime. This adds a desktop override/runtime case to the CLI and desktop reports already in this issue. No user paths, repo names, credentials, or raw logs are included.

Adding one path that the patch in this thread does not cover, plus the mechanism why the windows are visible even when Codex itself owns a console.

Environment

Windows 11 10.0.26200, Windows Terminal 1.24.11911 set as default terminal application
codex-cli 0.157.1, TUI launched in a Windows Terminal tab (so the Codex process has a console)
~/.codex/config.toml: [windows] sandbox = "elevated", default hooks (command hooks on PreToolUse/PostToolUse/SessionStart/Stop), lean-ctx + omx hooks configured

Repro: run codex in a WT tab, send a single message. Black console windows flash for the whole turn (one per sandboxed command; the count scales with the number of hooks/tool calls).

Why it is visible although Codex has a console (cross-account detail)

$ codex sandbox whoami
desktop-7e8rpqh\codexsandboxoffline

$ codex -c windows.sandbox="unelevated" sandbox whoami
desktop-7e8rpqh\<user>

create_process_as_user launches the child with the sandbox account's token, i.e. a different local user. A child owned by another account cannot attach to the console owned by your user, so Windows must allocate a new console for it — and with console_flags = 0 that console is visible (the default terminal application renders it as a flashing Windows Terminal window). In unelevated mode the same call uses the caller's own restricted token, so the child attaches to the existing console and no window is created. I verified the conhost ownership differs exactly this way:

elevated: conhost.exe <- cmd.exe <- codex-command-runner-0.157.1.exe <- codex.exe (child got its own console)
unelevated: no conhost child for the sandboxed cmd.exe (it attached to the caller's console)

The same spawn failure mode also produces the 0x800700E8 / ERROR_NO_DATA (232) "git probe" windows reported in #48601 — see the comment there for the error path (CreateProcessAsUserW failed: 232 (管道正在被关闭) | … | cmd=git … core.fsmonitor).

Gap left by the patch above

The patch changes (None, ConsoleMode::NoWindow) in process.rs and switches unified_exec/backends/legacy.rs to NoWindow, but leaves the matrix branch (Some(_), ConsoleMode::Inherit) => 0 untouched. The elevated capture path still passes pipes together with Inherit:

codex-rs/windows-sandbox-rs/src/lib.rs#L760-L769 — run_windows_sandbox_capture / run_windows_sandbox_capture_with_filesystem_overrides:

create_process_as_user(
    security.h_token,
    &command, cwd, &env_map, logs_base_dir,
    Some((in_r, out_w, err_w)),   // pipe-backed
    ConsoleMode::Inherit,         // → console_flags = 0  → new *visible* console
    desktop,
)

So with that patch applied, sandboxed commands on this path keep allocating a visible console every time.

Suggested fix

Either switch those two call sites to ConsoleMode::NoWindow as well, or make the matrix hide the console for every pipe-backed spawn, which is the safer default because a pipe-backed child never needs a console:

let console_flags = match (&stdio, console_mode) {
    (Some(_), ConsoleMode::NoWindow) => CREATE_NO_WINDOW,
    (Some(_), ConsoleMode::Inherit) => CREATE_NO_WINDOW,
    (None, ConsoleMode::Inherit) => 0,
    (None, ConsoleMode::NoWindow) => CREATE_NO_WINDOW,
};

Related: #44768, #48023, #48152, #48826, and #48601 for the 0x800700E8 git-probe variant of the same spawn.

Same issue on Windows 11. Seriously considering switching to Linux now :(

As for me,I can only use Codex CLI on Ubuntu and can`t use ChatGPT desktop app. B23042212殷智元 ***@***.***

Still reproducible on codex-cli 0.158.0. --no-daemon avoids the issue.

Also affected on Windows using PowerShell and Windows Terminal, with both the CLI and the running shared daemon on 0.157.1.

Updating the daemon from 0.157.0 to 0.157.1 using codex app-server daemon update --from-cli did not resolve the problem. The update reported both installedVersion and runningVersion as 0.157.1. Previously persistent helper terminal windows closed during the restart, but terminal windows still repeatedly flash open and close during normal use.

Before the update, the shared daemon's child processes included node_repl.exe, node.exe running cua-repl.mjs, cmd.exe launching Playwright MCP, and codex-code-mode-host.exe. I have not yet traced which processes create the brief flashes after the update.

The repeated popups are highly disruptive when working with multiple Codex sessions. Adding this as another reproduction on 0.157.1; I am not claiming a confirmed source-level root cause.

We thought we fully understood the cause and included a fix in 0.158.0. It sounds like some of you are still seeing the problem with the latest version. If so, could you please confirm that your daemon (background server) is also running 0.158.0? You can tell by using /status, which should report the daemon version.

If you are running 0.158.0 for the daemon and you're still seeing this problem, then we could use some additional help in diagnosing the cause. This isn't happening for all users, and we are not seeing it in any of our internal testing, so there's likely something specific about some of your setups (a specific Windows version, specific MCPs, a specific brand of antimalware installed, etc.) that causes the problem to occur. It would help if you could repro the problem and then use /feedback to upload your logs and post the session ID here.

fyi, i just updated my codex and it seems it's now fixed on my machine. but since there's still some people have this issue, i think this issue should be keep opening for more while.

update: just noticed a window flash briefly when executing "Implement the plan" from plan mode. however, the issue has been significantly alleviated.

This might be helpful

I captured the streak in this session: one batch of three tool calls opened three new Windows Terminal windows within 170 ms, all titled with the daemon’s codex-windows-sandbox-setup.exe path. A second batch produced another three. That explains why you sometimes see one flash and sometimes several.

The cause is specific: Codex 0.158.0’s sandbox refresh launch omits CREATE_NO_WINDOW, while its [other setup launch](https://github.com/openai/codex/blob/rust-v0.158.0/codex-rs/windows-sandbox-rs/src/setup.rs#L926-L938) sets it. The detached daemon has no console for that helper to inherit; --no-daemon avoids the flash because the session runs in your terminal. The omission is still in current main.

The git.exe flash reported in issue #48422 may be an additional launch path; this capture established the sandbox helper streak specifically. The upstream fix should add CREATE_NO_WINDOW to run_setup_refresh_payload and address Git launches separately. My earlier Git-only diagnosis missed the tool-call cause.

I still have the error
ID 01a0e92d-aed0-7ff1-a55d-e3c490631a47

Additional instrumented reproduction on stable 0.158.0, responding to the request to confirm the daemon version.

Both the standalone CLI and the managed daemon use the official 0.158.0-x86_64-pc-windows-msvc package. Their codex.exe files have the same SHA-256:

AF02050CC0C95F5AEB714AF2C1077E635C58E9896C13C89D75099CF5B96477BE

Environment: Windows x64, OS version 10.0.26200.0, Windows Terminal, PowerShell 7, Git 2.45.2.windows.1.

Observed startup path

Starting a normal CLI session in a Git workspace still causes rapid visible terminal flashes. A bounded process monitor recorded four git.exe processes directly parented by the managed daemon. Immediately afterward, Windows Terminal had a nonzero main-window handle and the title C:\Program Files\Git\cmd\git.exe.

A read-only inspection of process parameters showed ConsoleHandle=0 for the production daemon. I am not attributing every historical flash or every shell-tool window to this one path.

Controlled reproduction outside the original project

I also reproduced the startup behavior using the same official 0.158.0 executable with app-server --listen stdio://, an isolated CODEX_HOME, a minimal Git repository, and a local stub MCP returning empty lists. The real project scripts, plugins and MCP servers were absent. No model turn was started.

The client performed initialize, sent initialized, then called thread/start with ephemeral: true and the Git repository as cwd. The server launch used Node's spawn with windowsHide: true in every case, alternating detached: false and detached: true. Each case had an equivalent fresh isolated configuration. The detached launches had no console; the non-detached launches had a hidden console.

Run	Detached	Server console handle	New OpenConsole processes observed	Direct Git children observed
1	false	nonzero	0	2
2	true	zero	3	3
3	false	nonzero	0	2
4	true	zero	3	3

Git-titled Windows Terminal windows were also observed in the detached runs. These are counts of newly observed console processes, not an exact count of visible windows. Sampling can miss short-lived processes, and a terminal title can briefly persist across runs. Merely observing conhost.exe was not treated as proof of visibility.

Remaining Git launch gap in stable 0.158.0

At release commit 064c6b8c737f5b41d171fdda80bd9ef10ad06eb3:

The daemon launcher uses DETACHED_PROCESS | CREATE_BREAKAWAY_FROM_JOB.
spawn_git_command passes a raw Tokio command to JobObject::spawn_contained; its fallback resets creation_flags(0).
prepare_suspended_spawn replaces creation flags with CREATE_SUSPENDED, without CREATE_NO_WINDOW.
The MCP launcher already handles this correctly by restoring CREATE_SUSPENDED | CREATE_NO_WINDOW after the helper. The Git path does not have the equivalent handling.

Please include this raw Tokio/Job Object Git path in the remaining fix: preserve process containment and suspension while applying CREATE_NO_WINDOW, including the fallback. Setting that flag before the current helper alone would be overwritten. This is a proposed source fix, not a compiled or validated patch.

A regression test should start the parent without a console and trigger Git metadata collection at session startup, while checking that no visible console appears. Keeping the shared daemon enabled is important; bypassing it does not address the underlying launch defect.

This report contains a sanitized summary, without session transcripts, credentials or personal project paths.

Confirming on a 0.158.0 daemon, with the unelevated sandbox, which the patch and analysis above do not cover.

Environment:

Windows 11 10.0.26200.9457, Windows Terminal 1.24.11911.0, default terminal left at "Let Windows decide" (resolves to Windows Terminal)
TUI codex-cli 0.157.1 in a Windows Terminal tab; managed daemon 0.158.0-x86_64-pc-windows-msvc (codex app-server --listen unix:// --managed-daemon)
[windows] sandbox = "unelevated"

Observed with AttachConsole per process: the TUI has a console, the managed daemon has none, codex-code-mode-host.exe has its own hidden one. ~/.codex/.sandbox/sandbox.<date>.log shows the daemon starting each tool call as powershell.exe -NoProfile -Command ... (daemon-routed commands first appear in the log on 2026-09-24). Windows flash in bursts matching parallel tool calls.

Control: codex exec (no daemon) ran three sandboxed commands, all logged in the same sandbox log, and a 100 ms EnumWindows diff plus a WMI process-start trace recorded zero new visible windows. codex features disable daemon_auto_start followed by codex app-server daemon stop stops it.

Why 0.158.0 does not fix this setup, on main at 3a16c0b:

unified_exec/mod.rs:59-88: any level other than Elevated (so RestrictedToken, the unelevated sandbox) takes backends::legacy.
unified_exec/backends/legacy.rs:118 and lib.rs:767 launch with ConsoleMode::Inherit and piped stdio.
process.rs:109-113 maps (Some(_), ConsoleMode::Inherit) to creation flags 0.
app-server-daemon/src/backend/windows.rs:142 and pid_start.rs:209 start the daemon with DETACHED_PROCESS, so there is no console to inherit and each child allocates a new one, which the default terminal shows.

The merged console fixes (#48138 code-mode host, #48238 MCP servers, #48483 utils/pty children) do not touch windows-sandbox-rs. The elevated command runner already passes ConsoleMode::NoWindow (bin/command_runner/win.rs:351); the legacy backend could do the same when stdio is piped, or create_process_as_user could add CREATE_NO_WINDOW when the caller has no console.

We think we've fixed the issue, but we could use your help validating the fix. I've posted instructions here.

I'm going to close this issue as a duplicate, and we'll use #48074 for additional discussions and updates on this topic.

Run piped legacy Windows sandbox processes without a console (#49308)

Navigation Menu

Repository navigation

Windows: visible console windows flash for shell process children on every session/turn #48422

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

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

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

This issue is written by codex and review by human.

Environment

Process evidence

Configuration checks

Expected behavior

6 remaining items

Environment

Why it is visible although Codex has a console (cross-account detail)

Gap left by the patch above

Suggested fix

Observed startup path

Controlled reproduction outside the original project

Remaining Git launch gap in stable 0.158.0

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows: visible console windows flash for shell process children on every session/turn #48422

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

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

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

This issue is written by codex and review by human.

Activity

github-actions commented on Sep 26, 2026

qwq233 commented on Sep 26, 2026

yecate commented on Sep 26, 2026

remcoros commented on Sep 26, 2026

gafapa commented on Sep 26, 2026

dideldei commented on Sep 26, 2026

Environment

Process evidence

Configuration checks

Expected behavior

chennqqi commented on Sep 27, 2026

Dieg0Code commented on Sep 27, 2026

starSumi commented on Sep 27, 2026

Olwiba commented on Sep 27, 2026

dushouke commented on Sep 27, 2026

6 remaining items

jack1415926 commented on Sep 28, 2026

freezed-corpse-143 commented on Sep 28, 2026

Environment

Why it is visible although Codex has a console (cross-account detail)

Gap left by the patch above

Suggested fix

TenofHearts commented on Sep 28, 2026

jack1415926 commented on Sep 28, 2026

jadchene commented on Sep 28, 2026

leiliuliulei commented on Sep 28, 2026

etraut-openai commented on Sep 28, 2026

qwq233 commented on Sep 28, 2026

remcoros commented on Sep 28, 2026

gafapa commented on Sep 28, 2026

JMauricioVLJunior commented on Sep 28, 2026

Observed startup path

Controlled reproduction outside the original project

Remaining Git launch gap in stable 0.158.0

kimlj commented on Sep 29, 2026

etraut-openai commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions