codex - 💡(How to fix) Fix [Bug] PTY Leak in Codex macOS Desktop App / Codex macOS 桌面端应用 PTY 泄漏问题 [1 comments, 1 participants]

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

Codex App version: 26.325.31654

What subscription do you have?

Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Description

After using the Codex desktop app on macOS for a while, it eventually fails to create new pseudo-terminals and starts showing the following errors:

[forkpty: Device not configured]
[未能创建新的进程和打开伪终端(pseudo-tty)。]

This appears to be a PTY leak in the macOS desktop app. The Codex main process keeps accumulating /dev/ptmx handles until the system PTY limit is exhausted.

Steps to Reproduce & Logs

At the time of failure, PTY usage showed the Codex main process holding 511 PTYs:

$ lsof /dev/ptmx | awk 'NR>1 {count[$1":"$2]++} END {for (k in count) print count[k], k}'
511 Codex:922

The PTY limit at the time was:

$ sysctl kern.tty.ptmx_max
kern.tty.ptmx_max: 511

So Codex had effectively exhausted the full PTY limit.

I also checked child shells under the Codex process and only saw a couple of zsh children, so this did not look like a normal accumulation of live shell processes:

$ ps -p 2970,4246 -o pid,ppid,stat,start,time,command
  PID  PPID STAT STARTED      TIME COMMAND
 2970   922 Ss+   8:06AM   0:00.30 /bin/zsh
 4246   922 Ss+   8:07AM   0:00.20 /bin/zsh

After fully quitting/restarting Codex, PTY usage dropped back down and the issue temporarily disappeared. For example:

$ lsof /dev/ptmx | wc -l
       6

Workaround Attempted: I later raised the PTY limit to 999 via a LaunchDaemon as a workaround, but that only masks the leak and does not solve the underlying issue.

Expected Behavior

Codex should release PTYs after commands/sessions complete and should not steadily increase /dev/ptmx usage over time.

Actual Behavior

During long sessions, the app appears to leak PTYs until new shell/process creation fails entirely.

Environment / Platform Details

$ uname -mprs
Darwin 24.6.0 arm64 arm

$ sw_vers
ProductName:        macOS
ProductVersion:     15.7.1
BuildVersion:       24G231

问题描述

在 macOS 上使用 Codex 桌面端应用一段时间后，它最终会无法创建新的伪终端，并开始显示以下错误：

[forkpty: Device not configured]
[未能创建新的进程和打开伪终端(pseudo-tty)。]

这似乎是 macOS 桌面端应用中的 PTY 泄漏问题。Codex 主进程不断积累 /dev/ptmx 句柄，直到耗尽系统的 PTY 限制。

复现步骤与日志

发生故障时，PTY 使用情况显示 Codex 主进程占用了 511 个 PTY：

$ lsof /dev/ptmx | awk 'NR>1 {count[$1":"$2]++} END {for (k in count) print count[k], k}'
511 Codex:922

当时的系统 PTY 限制为：

$ sysctl kern.tty.ptmx_max
kern.tty.ptmx_max: 511

因此，Codex 实际上已经耗尽了全部的 PTY 限制。

我还检查了 Codex 进程下的子 shell，只看到了几个 zsh 子进程，所以这看起来不像是因为存活的 shell 进程正常积累所导致的：

$ ps -p 2970,4246 -o pid,ppid,stat,start,time,command
  PID  PPID STAT STARTED      TIME COMMAND
 2970   922 Ss+   8:06AM   0:00.30 /bin/zsh
 4246   922 Ss+   8:07AM   0:00.20 /bin/zsh

在完全退出并重新启动 Codex 后，PTY 使用率回落，问题暂时消失。例如：

$ lsof /dev/ptmx | wc -l
       6

尝试过的临时方案： 后来，我通过 LaunchDaemon 将 PTY 限制提高到 999 作为临时解决办法，但这只是掩盖了泄漏的表现，并没有解决根本问题。

预期行为

Codex 应该在命令/会话完成后释放 PTY 资源，而不应该随着时间的推移不断增加对 /dev/ptmx 的占用。

实际行为

在长时间运行的会话中，该应用似乎会持续泄漏 PTY，直到完全无法创建新的 shell 或进程。

环境 / 平台详情

$ uname -mprs
Darwin 24.6.0 arm64 arm

$ sw_vers
ProductName:        macOS
ProductVersion:     15.7.1
BuildVersion:       24G231

What steps can reproduce the bug?

Reproduction Steps & Context

Currently, there is no minimal deterministic reproduction. The issue typically surfaces after prolonged interactive use of the Codex macOS desktop app.

Steps taken before failure:

1. Keep the Codex desktop app open for an extended, long-running session.
2. Repeatedly use Codex to execute shell/tool actions that require PTY allocation.
3. Continue normal interactive use until the creation of new shells or processes begins to fail.

Symptoms: When the issue occurs, Codex starts displaying the following errors:

[forkpty: Device not configured]
[未能创建新的进程和打开伪终端(pseudo-tty)。]

Observations: At the point of failure, checking /dev/ptmx usage reveals that the Codex main process is holding hundreds of PTY handles, eventually exhausting the system limit. This behavior does not appear to be tied to any specific repository or prompt; rather, it is directly related to long-running desktop app sessions involving repeated PTY allocations.

复现步骤与背景信息

目前尚未找到最小化的确定性复现方法。该问题通常在 macOS 系统上长时间交互使用 Codex 桌面端应用后出现。

故障发生前的操作步骤：

1. 保持 Codex 桌面端应用在一个长会话中持续处于打开状态。
2. 频繁使用 Codex 运行会创建 PTY 的 shell 或工具操作。
3. 继续正常的交互使用，直到应用开始无法创建新的 shell 或进程。

症状表现： 当问题发生时，Codex 会开始显示以下错误提示：

[forkpty: Device not configured]
[未能创建新的进程和打开伪终端(pseudo-tty)。]

观察结果： 在发生故障时，检查 /dev/ptmx 的使用情况可以发现，Codex 主进程占用了数百个 PTY 句柄，并最终达到了系统的最大限制。该问题似乎与特定的代码仓库或提示词（prompt）无关，而是直接与伴随频繁 PTY 分配的长时间桌面端运行会话有关。

What is the expected behavior?

Expected Behavior

Codex should release PTYs after commands or interactive sessions complete and should not steadily accumulate /dev/ptmx handles during normal desktop app usage.

Even during long-running sessions, the app should remain able to create new shells/processes and should never exhaust the system PTY limit.

预期行为

Codex 应该在命令或交互式会话完成后释放 PTY 资源，且在正常的桌面端应用使用过程中，不应持续积累 /dev/ptmx 句柄。

即使在长时间运行的会话中，应用也应始终保持创建新 shell 或进程的能力，绝不应耗尽系统的 PTY 限制。

Additional information

Detailed Logs & Investigation

At the time of failure, I checked PTY usage and found the Codex main process holding 511 PTYs:

$ lsof /dev/ptmx | awk 'NR>1 {count[$1":"$2]++} END {for (k in count) print count[k], k}'
511 Codex:922

The PTY limit at the time was:

$ sysctl kern.tty.ptmx_max
kern.tty.ptmx_max: 511

So Codex had effectively exhausted the full PTY limit.

I also checked child shells under the Codex process and only saw a couple of zsh children, indicating this did not look like a normal accumulation of live shell processes:

$ ps -p 2970,4246 -o pid,ppid,stat,start,time,command
  PID  PPID STAT STARTED      TIME COMMAND
 2970   922 Ss+   8:06AM   0:00.30 /bin/zsh
 4246   922 Ss+   8:07AM   0:00.20 /bin/zsh

After fully quitting and restarting Codex, PTY usage dropped back down and the issue temporarily disappeared:

$ lsof /dev/ptmx | wc -l
       6

I initially tried to increase the PTY limit dynamically, but 1024 was rejected by the system:

$ sudo sysctl -w kern.tty.ptmx_max=1024
Password:
kern.tty.ptmx_max: 511
sysctl: kern.tty.ptmx_max=1024: Invalid argument

Workaround: As a workaround, I later raised the PTY limit to 999 via a LaunchDaemon, but that only masks the leak and does not solve the underlying issue.

Platform Details

$ uname -mprs
Darwin 24.6.0 arm64 arm

$ sw_vers
ProductName:        macOS
ProductVersion:     15.7.1
BuildVersion:       24G231

详细日志与排查过程

在发生故障时，我检查了 PTY 的使用情况，发现 Codex 主进程占用了 511 个 PTY：

$ lsof /dev/ptmx | awk 'NR>1 {count[$1":"$2]++} END {for (k in count) print count[k], k}'
511 Codex:922

当时的系统 PTY 限制为：

$ sysctl kern.tty.ptmx_max
kern.tty.ptmx_max: 511

因此，Codex 实际上已经耗尽了全部的 PTY 限制。

我还检查了 Codex 进程下的子 shell，只看到了几个 zsh 子进程，这表明它看起来并不像是存活 shell 进程的正常积累：

$ ps -p 2970,4246 -o pid,ppid,stat,start,time,command
  PID  PPID STAT STARTED      TIME COMMAND
 2970   922 Ss+   8:06AM   0:00.30 /bin/zsh
 4246   922 Ss+   8:07AM   0:00.20 /bin/zsh

在完全退出并重新启动 Codex 后，PTY 的使用率回落，问题暂时消失：

$ lsof /dev/ptmx | wc -l
       6

最初，我尝试动态增加 PTY 的限制，但 1024 这个值被系统拒绝了：

$ sudo sysctl -w kern.tty.ptmx_max=1024
Password:
kern.tty.ptmx_max: 511
sysctl: kern.tty.ptmx_max=1024: Invalid argument

临时解决方案： 后来，我作为临时解决办法，通过 LaunchDaemon 将 PTY 限制提高到了 999，但这只是掩盖了泄漏的表象，并没有解决根本问题。

平台详情

$ uname -mprs
Darwin 24.6.0 arm64 arm

$ sw_vers
ProductName:        macOS
ProductVersion:     15.7.1
BuildVersion:       24G231