Codex desktop embedded terminal closes immediately in every thread

Open 💬 2 comments Opened Jun 3, 2026 by xairliber-byte

What version of the Codex App are you using (From “About Codex” dialog)?

Codex desktop app 26.601.2237.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

The Codex desktop app appears to have two related environment issues on Windows.

First, the embedded terminal closes immediately in every Codex chat thread. Normal Windows PowerShell opens and works outside Codex.

Second, commands run by Codex cannot access the same Lark CLI authentication state that normal PowerShell can access. Normal PowerShell uses the same lark-cli path and the same config file, and it reports valid user authentication. Inside Codex, the same lark-cli path and config file are visible, but lark-cli auth status reports no_token.

Codex also cannot reach Lark/Feishu HTTPS endpoints from its execution environment. lark-cli doctor inside Codex reports Windows socket permission errors such as:

connectex: An attempt was made to access a socket in a way forbidden by its access permissions.

This prevents Codex from directly accessing Lark documents through lark-cli, even though the same commands work in normal Windows PowerShell.

What steps can reproduce the bug?

  1. Open Codex desktop on Windows.
  2. Open any chat thread.
  3. Click the Terminal button.
  4. Observe that the terminal closes immediately or does not attach to the thread.
  5. Open normal Windows PowerShell outside Codex.
  6. Run:

Get-Command lark-cli | Format-List Path
lark-cli config show
lark-cli auth status
lark-cli auth check --scope "docx:document:readonly"

  1. Normal PowerShell reports the same CLI path and config path, and auth check returns ok: true.
  2. Ask Codex to run:

lark-cli auth status
lark-cli auth check --scope "docx:document:readonly"
lark-cli doctor

  1. Inside Codex, lark-cli auth status reports no_token, auth check reports no_token, and lark-cli doctor reports outbound HTTPS failures to Feishu/Lark endpoints with connectex socket permission errors.

Observed normal PowerShell details:
CLI path: C:\Users\Admin\AppData\Roaming\npm\lark-cli.ps1
Config file: C:\Users\Admin\.lark-cli\config.json
User auth: valid
Scope check: docx:document:readonly ok: true

Observed Codex details:
Same CLI path and same config file are visible, but user identity is missing with no_token.

What is the expected behavior?

The Codex desktop embedded terminal should open and remain attached to the current thread.

Commands run by Codex should be able to use the same local CLI environment as normal Windows PowerShell, including the same lark-cli path, config and saved authentication state for the same Windows user.

Codex should also be able to make outbound HTTPS requests from its execution environment when the user has granted network access, so tools like lark-cli can reach accounts.feishu.cn, open.feishu.cn, mcp.feishu.cn and bytedance.larkoffice.com.

Additional information

This is not a Lark document permission issue. The user owns or has access to the Lark documents. Normal Windows PowerShell can authenticate with lark-cli successfully and can fetch the documents.

The issue seems specific to the Codex desktop app environment. It either cannot access the same stored credentials, cannot make outbound HTTPS connections, or both. The embedded terminal also fails independently by closing immediately in every thread.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗