Git branch names fail to display in the statusline with these settings.

What version of Codex CLI is running?

0.132

What subscription do you have?

none

Which model were you using?

gpt-5.5

What platform is your computer?

windows

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

powershell

Codex doctor report

{
  "schemaVersion": 1,
  "generatedAt": "1779410699s since unix epoch",
  "overallStatus": "fail",
  "codexVersion": "0.132.0",
  "checks": {
    "app_server.status": {
      "id": "app_server.status",
      "category": "app-server",
      "status": "ok",
      "summary": "background server is not running",
      "details": {
        "control socket": "C:\\Users\\CMJ\\.codex\\app-server-control\\app-server-control.sock",
        "daemon state dir": "C:\\Users\\CMJ\\.codex\\app-server-daemon",
        "mode": "ephemeral",
        "pid file": "C:\\Users\\CMJ\\.codex\\app-server-daemon\\app-server.pid (missing)",
        "settings": "C:\\Users\\CMJ\\.codex\\app-server-daemon\\settings.json (missing)",
        "status": "not running",
        "update-loop pid file": "C:\\Users\\CMJ\\.codex\\app-server-daemon\\app-server-updater.pid (missing)"
      },
      "remediation": null,
      "durationMs": 0
    },
    "auth.credentials": {
      "id": "auth.credentials",
      "category": "auth",
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth file": "C:\\Users\\CMJ\\.codex\\auth.json",
        "auth storage mode": "File",
        "stored API key": "true",
        "stored ChatGPT tokens": "false",
        "stored agent identity": "false",
        "stored auth mode": "api_key"
      },
      "remediation": null,
      "durationMs": 0
    },
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "C:\\Users\\CMJ\\.codex",
        "config.toml": "C:\\Users\\CMJ\\.codex\\config.toml",
        "config.toml parse": "ok",
        "cwd": "E:\\Workspace",
        "enabled feature flags": "shell_tool, shell_snapshot, terminal_resize_reflow, sqlite, hooks, enable_request_compression, multi_agent, apps, tool_search, tool_suggest, plugins, plugin_hooks, in_app_browser, browser_use, browser_use_external, computer_use, plugin_sharing, image_generation, skill_mcp_dependency_install, steer, guardian_approval, collaboration_modes, tool_call_mcp_elicitation, personality, fast_mode, tui_app_server, workspace_dependencies",
        "feature flag overrides": "none",
        "feature flags enabled": "27",
        "log dir": "C:\\Users\\CMJ\\.codex\\log",
        "mcp servers": "1",
        "model": "gpt-5.5",
        "model provider": "OpenAI",
        "sqlite home": "C:\\Users\\CMJ\\.codex"
      },
      "remediation": null,
      "durationMs": 0
    },
    "installation": {
      "id": "installation",
      "category": "install",
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "PATH codex #1": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\codex",
        "PATH codex #2": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\codex.cmd",
        "PATH codex entries": "2",
        "current executable": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex\\codex.exe",
        "install context": "npm",
        "managed by bun": "false",
        "managed by npm": "true",
        "managed package root": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex",
        "npm update target": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex"
      },
      "remediation": null,
      "durationMs": 405
    },
    "mcp.config": {
      "id": "mcp.config",
      "category": "mcp",
      "status": "ok",
      "summary": "MCP configuration is locally consistent",
      "details": {
        "configured servers": "1",
        "disabled servers": "0",
        "stdio servers": "1"
      },
      "remediation": null,
      "durationMs": 6
    },
    "network.env": {
      "id": "network.env",
      "category": "network",
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.provider_reachability": {
      "id": "network.provider_reachability",
      "category": "reachability",
      "status": "fail",
      "summary": "one or more required provider endpoints are unreachable over HTTP",
      "details": {
        "OpenAI API base URL": "http://192.168.3.16:3200 request timed out (required)",
        "reachability mode": "API key auth"
      },
      "remediation": "Check proxy, VPN, firewall, DNS, and custom CA configuration.",
      "durationMs": 3019
    },
    "network.websocket_reachability": {
      "id": "network.websocket_reachability",
      "category": "websocket",
      "status": "ok",
      "summary": "Responses WebSocket is not enabled for the active provider",
      "details": {
        "model provider": "OpenAI",
        "provider name": "OpenAI",
        "proxy env vars": "none",
        "supports websockets": "false",
        "wire API": "responses"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.provenance": {
      "id": "runtime.provenance",
      "category": "runtime",
      "status": "ok",
      "summary": "running npm on windows-x86_64",
      "details": {
        "commit": "unknown",
        "current executable": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex\\codex.exe",
        "install method": "npm",
        "platform": "windows-x86_64",
        "version": "0.132.0"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.search": {
      "id": "runtime.search",
      "category": "search",
      "status": "ok",
      "summary": "search is OK (system)",
      "details": {
        "search command": "rg.exe",
        "search command readiness": "ripgrep 15.1.0 (rev af60c2de9d)",
        "search provider": "system"
      },
      "remediation": null,
      "durationMs": 272
    },
    "sandbox.helpers": {
      "id": "sandbox.helpers",
      "category": "sandbox",
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "OnRequest",
        "codex-linux-sandbox helper": "none",
        "execve wrapper helper": "none",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      },
      "remediation": null,
      "durationMs": 0
    },
    "state.paths": {
      "id": "state.paths",
      "category": "state",
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "CODEX_HOME": "C:\\Users\\CMJ\\.codex (dir)",
        "active rollout files": "42 files, 25233260 total bytes, 600791 average bytes",
        "archived rollout files": "0 files, 0 total bytes, 0 average bytes",
        "log DB": "C:\\Users\\CMJ\\.codex\\logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "log dir": "C:\\Users\\CMJ\\.codex\\log (dir)",
        "sqlite home": "C:\\Users\\CMJ\\.codex (dir)",
        "state DB": "C:\\Users\\CMJ\\.codex\\state_5.sqlite (file)",
        "state DB integrity": "ok"
      },
      "remediation": null,
      "durationMs": 2915
    },
    "terminal.env": {
      "id": "terminal.env",
      "category": "terminal",
      "status": "ok",
      "summary": "terminal metadata was detected",
      "details": {
        "WT_SESSION": "present",
        "color output": "enabled",
        "stderr is terminal": "true",
        "stdin is terminal": "true",
        "stdout is terminal": "true",
        "terminal": "Windows Terminal",
        "terminal size": "120x30"
      },
      "remediation": null,
      "durationMs": 1
    },
    "updates.status": {
      "id": "updates.status",
      "category": "updates",
      "status": "warning",
      "summary": "update configuration is locally consistent",
      "details": {
        "cached latest version": "0.132.0",
        "check for update on startup": "true",
        "last checked at": "2026-05-21T03:07:58.736275500Z",
        "latest version probe": "curl: (28) Operation timed out after 5013 milliseconds with 8287 out of 242098 bytes received",
        "npm update target": "C:\\Users\\CMJ\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex",
        "update action": "npm install -g @openai/codex",
        "version cache": "C:\\Users\\CMJ\\.codex\\version.json"
      },
      "remediation": null,
      "durationMs": 5313
    }
  }
}

What issue are you seeing?

no

What steps can reproduce the bug?

Windows PowerShell configuration: sandbox = "elevated", approval_policy = "on-request", sandbox_mode = "workspace-write". Git branch names fail to display in the statusline with these settings.

What is the expected behavior?

not possible

Additional information

Windows PowerShell configuration: sandbox = "elevated", approval_policy = "on-request", sandbox_mode = "workspace-write". Git branch names fail to display in the statusline with these settings.

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

Windows TUI render corruption in git repos triggered by core.fsmonitor=false git metadata call #23888

Powered by Codex Action

Why statusline does not display Git branches
I first confirmed the source of the current directory's Git status and statusline configuration:
If the current directory is not a workspace or the command configured to fetch branches fails, the status bar will not display branches.
The Codex itself is the Git workspace, and the current branch can be correctly parsed as cjsybank-20260606. Next, I checked Codex's statusline configuration and logs, focusing on whether the actual executed command fetched this branch.
The configuration already includes git-branch, so the problem is not a missing configuration. Now I will check the statusline initialization logs and Codex version to determine if it is caused by log truncation, version incompatibility, or runtime directory errors.
I have confirmed three times that git-branch is enabled and the current warehouse can fetch branches. Codex version is 0.131.0. I will only paste the statusline initialization log segment to avoid interference from the entire Codex log history.
The troubleshooting direction is now clear: it is not a problem with the warehouse itself or a missing git-branch configuration. I will extract the specific project logs where the status bar truncates information for the last time to confirm whether Codex included this item.
The reasons that can be ruled out:
The current directory is a Git repository.
The current branch can be fetched normally: cjsybank-20260606.
git-branch is already configured in C:\Users\CNJ.codex\config.toml.
Codex logs also show that the status bar has recognized GitBranch.
So the most likely reason is: the statusline content is too long, and when the terminal width is insufficient, subsequent items are squeezed out or not displayed. In your configuration, git-branch is placed at a relatively rear position.
status_line = ["model-with-reasoning", "context-window-size", "context-used", "used-tokens", "project-name", "git-branch", "run-state"]
The preceding models, context, tokens, and project names already occupy a lot of width. The branch name is also cjsybank-20260606, which cannot be displayed when the window is not wide enough.
It is recommended to move git-branch forward or remove unnecessary items, for example:
toml
[
tui
]
status_line = ["git-branch", "project-name", "model-with-reasoning", "context-used", "run-state"]
Restart Codex TUI after modification. You can also first drag the terminal window to widen it to verify; the branch should appear when the width is sufficient.
Key point: run-state can always display normally [Image #1]
Your previous diagram overturned the "purely width truncation" judgment: run-state is still displayed after git-branch, indicating that the GitBranch item was skipped. Now I will explore why it failed to fetch the branch instead of being truncated.
The sandbox is only executing commands that trigger a Windows runner error. I changed to use elevated permissions to check and verify again whether Codex itself can call Git normally when running, and whether its branch parsing logic depends on a working directory.
The branch itself is fine: git branch --show-current returns cjsybank-20260606, and git status --branch is also normal. The next step is to check if there is no Git information recorded in the Codex session context; if there is no Git information in the context, the status bar will directly receive empty values.
You are right. Ready can be displayed normally, indicating that it is not the subsequent content being truncated, but the git-branch item itself is empty. I will continue to debug locally and check the Codex session context, aiming to confirm whether it only reads the "warehouse information cache" somewhere.
Test results for git-branch: Both git branch --show-current and git status --branch can get cjsybank-20260606, so the empty value is not caused by the Git warehouse itself. Now I want to look at the Codex status bar implementation to confirm how GitBranch obtains values.
Searched site:github.com/openai/codex "GitBranch" "status line"
Searched repo:openai/codex GitBranch StatusLineItem
Searched https://raw.githubusercontent.com/openai/codex/main/codex-rs/tui/src/chatwidget.rs
Searched GitBranch in https://raw.githubusercontent.com/openai/codex/main/codex-rs/tui/src/chatwidget.rs
Searched https://raw.githubusercontent.com/openai/codex/main/codex-rs/tui/src/status/surfaces.rs
Searched https://github.com/openai/codex/blob/main/codex-rs/tui/src/branch_summary.rs
Searched https://github.com/openai/codex/refs/heads/main/codex-rs/tui/src/branch_summary.rs
Found the key point from the source code: git-branch does not directly take values from the Git executed in the current terminal. Instead, it goes through Codex's workspace_command_runner to asynchronously run git branch --show-current; if it fails, it returns None, and the status bar directly skips this item without reporting an error. Combining with your Windows runner 1312 error, the direction is now very clear.
Searched 'show-current' in https://github.com/openai/codex/blob/main/codex-rs/tui/src/branch_summary.rs
Searched run_git_command in https://github.com/openai/codex/blob/main/codex-rs/tui/src/branch_summary.rs
Searched github openai codex WorkspaceCommandRunner "run" "WorkspaceCommand"
Searched site:github.com/openai/codex sandbox_mode windows sandbox elevated config.toml
Searched site:github.com/openai/codex "windows.sandbox" "none"
Searched site:github.com/openai/codex/blob/main/codex-rs/tui/src/workspace_command.rs "WorkspaceCommandExecutor"
Searched https://raw.githubusercontent.com/openai/codex/main/codex-rs/tui/src/workspace_command.rs
Yes, your judgment is correct. My previous statement about "width truncation" is not valid.
The actual reason is: run-state is a TUI internal state, directly displayed; git-branch is not an internal state, it will be executed in the background through Codex's app-server / workspace-command.
git branch --show-current
In the source code, this command directly returns None if it fails, and then this section of the status bar is omitted without displaying any errors. Reference: In Codex's branch_summary.rs, git branch --show-current returns empty after failure.
workspace_command.rs indicates that the status bar and other similar commands are sent to app-server/exec.
Your local Git is fine, I verified it:
plaintext
git branch --show-current

cjsybank-20260606
But Codex logs show a large number of:
windows sandbox: runner error: CreateProcessAsUserW failed: 1312
So the conclusion is: When fetching branches in the background for the status bar, it uses the Windows sandbox runner, which failed due to a path issue; after failure, git-branch is silently hidden. Ready is not affected because it does not need to call external commands.
Temporary verification method: Start Codex with non-sandbox/full access to see if the branch appears. The trade-off is that tool commands will no longer be restricted by workspace-write. A more stable fix can only be to repair the Codex Windows sandbox runner path, or switch to an environment where this Windows sandbox runner is not triggered.
What are the available options for the sandbox_mode configuration?

When sandbox_mode = "workspace-write", the Git branch name is not displayed; when sandbox_mode = "danger-full-access", it can be displayed normally.

Confirmed still reproducible on Codex CLI 0.147.0 on native Windows (PowerShell), using workspace-write sandboxing. The status line config includes git-branch, and the /statusline picker shows the sample value feat/awesome-feature, but the item disappears immediately after leaving the picker. This is not width truncation: the terminal is over 200 columns wide. The repository and session working directory are correct, and external Git resolves the branch normally: git branch --show-current and git symbolic-ref -q --short HEAD both return main. Reproduces after repeated restarts and with resumed sessions.

are you in a git worktree?

are you in a git worktree?

I was on main, same issue with other branches, it just doesn't show.

Confirmed still reproducible with Codex CLI 0.153.2 on native Windows.

Environment:

Codex CLI 0.153.2, installed via npm (windows-x86_64)
Windows 11 Pro 10.0.26200
Windows Terminal + PowerShell 7
Terminal width: 209 columns
Git for Windows 2.46.0

Minimal reproduction:

codex -c 'tui.status_line=["git-branch","branch-changes","pull-request-number"]'

The footer contains none of the three configured Git items. I repeated the launch with a temporary Windows sandbox override:

codex -c 'windows.sandbox="unelevated"' -c 'tui.status_line=["git-branch","branch-changes","pull-request-number"]'

The result was identical, so switching between the native Windows elevated and unelevated implementations does not fix it.

Diagnostics:

codex doctor --all reports repo detected: true and detects the current branch correctly.
git branch --show-current returns the branch correctly.
The working tree has uncommitted files, so branch-changes has data to display.
GitHub CLI authentication works and an open PR for the current branch resolves successfully, but pull-request-number is also omitted.
This is not width truncation; the test used a 209-column terminal and only the three Git items were configured.
Non-Git status-line items such as model-with-reasoning render normally when configured.

This appears to be the same silent failure path as the original report, but it now affects all three Git-derived status-line items and remains present in 0.153.2.

Confirmed on the unmodified Codex CLI 0.153.4 on native Windows with workspace-write and [windows] sandbox = "elevated". I isolated a deterministic failure before Git starts.

Root cause

The TUI's background workspace runner sends command/exec with outputBytesCap: 65536. The Windows sandbox execution path rejects every effective cap except the server default, 1048576, returning:

{"code":-32600,"message":"custom outputBytesCap is not supported with windows sandbox"}

current_branch_name discards the command error and returns None, so git-branch silently disappears. This also explains why selecting only git-branch leaves an empty footer while external Git and codex doctor resolve the branch correctly.

Source references, pinned to main commit 121f91fd5d9dc66017866ce9bdc49f1e182721df (September 7, 2026), where the same code is still present:

RPC reproduction

Start codex app-server --listen stdio:// using the configuration above. Initialize with capabilities.experimentalApi = true, send initialized, then send this request with cwd replaced by an existing Git repository:

{"id":2,"method":"command/exec","params":{"command":["git","-c","safe.bareRepository=explicit","branch","--show-current"],"cwd":"C:/path/to/repo","env":{"GIT_OPTIONAL_LOCKS":"0"},"timeoutMs":5000,"outputBytesCap":65536,"tty":false,"streamStdin":false,"streamStdoutStderr":false}}

Keeping the command, repository, permissions and sandbox configuration identical produced:

Request cap	Observed result on 0.153.4
`65536`	RPC error `-32600` above
Omitted	`exitCode: 0`, correct branch on stdout, empty stderr
`1048576`	`exitCode: 0`, correct branch on stdout, empty stderr

Possible fix and regression coverage

A candidate fix for bounded metadata lookups is to leave outputBytesCap unset with disableOutputCap: false and use the app-server's bounded default. This avoids duplicating the server's numeric default in the TUI or choosing behavior based on the local client's OS when the server may be remote. It would intentionally change the metadata capture limit on all platforms from 64 KiB to the current server default of 1 MiB.

The regression test should exercise the actual workspace-runner request through the Windows sandbox RPC path and assert a successful branch lookup. Existing tests with a mocked runner do not exercise the incompatible cap validation.

This limited fix would not fully resolve #28649: /diff explicitly requests uncapped output. Supporting its request requires the Windows execution backend to honor that capture policy; changing the metadata default alone is insufficient.

The RPC comparison above was executed against the released binary. The suggested source change has not been built or tested. No sandbox-permission change was needed for the successful RPC cases.

Navigation Menu

Repository navigation

Git branch names fail to display in the statusline with these settings. #23968

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

Root cause

RPC reproduction

Possible fix and regression coverage

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Git branch names fail to display in the statusline with these settings. #23968

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

Activity

github-actions commented on May 22, 2026

mujuncool commented on May 22, 2026

mujuncool commented on May 22, 2026

mozophe commented on Aug 13, 2026

hailiangliu89 commented on Sep 2, 2026

mozophe commented on Sep 2, 2026

Burjuy commented on Sep 4, 2026

bronekot commented on Sep 7, 2026

Root cause

RPC reproduction

Possible fix and regression coverage

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions