[tonyfettes]

Problem

spawn ties the pty to its task group: the terminal's file descriptors stay open until the group exits, even after the child has exited and been waited for. Measured on macOS, 50 finished ptys in one group held 50 descriptors until the group exited. A long-lived group (a terminal server, say) accumulates them without bound.

Change

let (text, exit_code) = @pty.with_pty("sh", ["-c", "echo hello"], pty => {
  let text = pty.read_all().text()
  (text, pty.wait())
})

with_pty takes spawn's arguments minus group and no_wait, runs the callback in a task group of its own, and releases the pty when the callback is done.

• It spawns with no_wait=true. Once the callback is done nobody reads the terminal, so waiting for a child that is still running could block forever on a full pty queue; instead it goes through the existing cancellation cleanup (hang up, 5 s grace period, kill) and with_pty returns once the child is reaped.
• It only calls spawn, so it lives in the shared pty.mbt with no #cfg and is type-checked on both platforms.
• spawn is unchanged and stays: it is what with_pty is built on, and it is still the right call when the pty must outlive its creator or share an existing group's lifetime.

.mbti gains one line (with_pty); nothing else changes.

Limitation, documented

A Pty that escapes the callback is closed, and a task still blocked reading it is not woken up (moonbitlang/async's close detaches the fd without waking waiters). The doc comment and README say to keep concurrent readers in a task group opened inside the callback.

Tests

Unix (run locally on macOS, 26 passed, three runs):

• returns the callback's result; pty.wait() inside the callback yields the exit code
• a child still running when the callback returns is ended and reaped before with_pty returns
• the pty is closed afterwards (resize raises EBADF)
• whitebox: 51 sessions reuse the same descriptor number (the same loop with spawn in one shared group climbs by 50)

Windows (not run locally; verified by CI only):

• returns the callback's result and the exit code
• the pty is closed afterwards

The callback returning while the child is still running takes the win32 cancellation path. That path is covered since #35 by the flooding-child test on spawn(no_wait=true), which is exactly the call with_pty makes, and #35 fixed the pre-24H2 ClosePseudoConsole hang Codex flagged here. There is no with_pty-specific test for it on Windows.

Rebased onto main after #35.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-11T07:44:12.789216Z	052adb9	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1987463b15

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Close the ConPTY output before cancelling the child

On Windows versions before 11 24H2, this no_wait path can hang indefinitely when f returns while the child is still producing output. The cancellation branch in pty_win32.mbt synchronously calls ClosePseudoConsole before the output reader is closed, while the reader is only closed by the task-group defer; Microsoft documents that older ClosePseudoConsole waits and can deadlock if its output pipe is neither closed nor drained. Thus a callback that does not consume all output—the exact full-queue case this wrapper is intended to handle—can prevent with_pty from ever reaching its grace-period kill or returning. Close the output pipe before closing the HPCON, or keep it draining concurrently during teardown. Microsoft's ClosePseudoConsole documentation.

AGENTS.md reference: AGENTS.md:L27-L31

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: be73de1b95

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Handle the ConPTY normal-exit race before cancellation

On Windows before 11 24H2, if f leaves the output unread and a finite high-output child exits before this no_wait task is cancelled, pty_win32.mbt:193-195 takes the normal Some(status) branch and its defer calls ClosePseudoConsole while the full output pipe remains open. That synchronous call can hang the event-loop thread indefinitely, so with_pty never returns despite its cleanup guarantee. This is distinct from the earlier comment: the parent fixed the still-running cancellation branch, while the fresh evidence here is the already-exited normal branch. Teardown after f must close the output reader before the HPCON even when the waiter has already observed process exit.

AGENTS.md reference: AGENTS.md:L27-L31

Useful? React with 👍 / 👎.