forkpty: Device not configured — Claude.app leaks pty masters until kern.tty.ptmx_max is exhausted (macOS)

Resolved 💬 0 comments Opened Jun 13, 2026 by jorgehellmann Closed Jun 22, 2026

Summary

The desktop app (Claude.app) appears to leak pty master file descriptors. Over a session, the main app process accumulates open /dev/ptmx handles — one per Bash/terminal command — without releasing them. Eventually it holds all available ptys and any new forkpty() fails with Device not configured, breaking both Claude Code's tool execution and any other app trying to open a terminal.

Environment

  • Claude.app version: 1.12603.1
  • macOS: 26.5.1 (build 25F80, Darwin 25.5.0)
  • kern.tty.ptmx_max: 511 (system default)

Symptom

forkpty: Device not configured
[Não foi possível criar um novo processo e abrir um pseudo-tty.]

Diagnosis

At the time of failure, /dev/ttys* nodes (527) exceeded kern.tty.ptmx_max (511). lsof showed one single process holding every pty master:

$ lsof /dev/ptmx | awk 'NR>1{print $1" (pid "$2")"}' | sort | uniq -c | sort -rn
 511 Claude (pid 1282)

So the Claude app process alone held 511 open /dev/ptmx masters — exactly the system limit. No other app was involved. This strongly indicates pty master fds are not being closed after each Bash tool command completes; they leak for the lifetime of the app process.

Impact

  • Once the limit is reached, all tool calls that spawn a process fail.
  • It also starves the rest of the OS — Terminal/iTerm/VS Code can't open new shells either.

Workaround

Fully quitting (⌘Q) and relaunching Claude.app releases all 511 ptys immediately. Raising kern.tty.ptmx_max only delays recurrence.

Expected

pty master fds should be closed once each tool command finishes, so open ptys stay roughly constant during a session instead of growing monotonically toward the system limit.

View original on GitHub ↗