Skip to content

[Bug]: Allow plain simulator launch without the detached console-PTY helper #552

Open

Description

@thesammykins

MobileBuildMCP 2.7.1 always uses a detached console-PTY helper in the public simulator launch-app and build-and-run paths. Please expose a plain launch option, and document that disabling the outer terminal's PTY does not disable this internal one.

Two host kernel panics occurred on macOS 27.2 beta 3 (26B5101f) during simulator launch. In each panic, the panicked simctl PID exactly matched the helper child PID recorded in MobileBuildMCP's generated log filename. The helper files were created seconds before their matching panic. This is stronger than timing correlation alone, but does not prove the underlying kernel race.

Both panic snapshots contained one simulator launcher/bridge and reported memoryPressure=false, pagesWanted=0, with available swap. Multiple booted simulators or memory exhaustion are not supported explanations for these two events.

Inspected launch path

The installed utils/simulator-steps.js launches:

xcrun simctl launch --console-pty --terminate-running-process <device> <bundle>

It uses detached: true, redirects output to a file, unrefs the child and records its PID in that filename. Both public launch tools select this logging implementation; neither inspected schema exposes a logging opt-out. A plain launchSimulatorApp implementation already exists in the same module. Running the CLI with ordinary pipes or tty: false still reaches the internal console-PTY path.

The local kernel binary's UUID matched both panic images. Bounded function/instruction/string inspection narrows the fault to PTY kqueue-detachment teardown: a null load at offset 0x18, references to tty_ptmx.c, tty_lock/tty_unlock, and the invalid-knote-detach diagnostic. This does not establish which stripped routine or exact race is responsible. The host kernel defect belongs to Apple; this request is for a way to avoid allocating a PTY when console capture is unnecessary.

Workaround observed

After owner-installed macOS/Xcode updates, compile-only build and install remained in MobileBuildMCP. Launch used a separate, explicit-device simctl launch <device> <bundle> with captured pipes, no detached console helper and no forced termination. The app was exercised on one persistent iPhone/iPad simulator at a time. This avoided the implicated helper; it is not a claim of a kernel repair or a controlled causal experiment.

Requested behavior

No deliberate kernel-panic reproducer was run. Raw panic reports, host paths, device IDs, app identifiers and system dumps are intentionally omitted. The reports above concern 2.7.1 and the affected beta host; they do not claim that released macOS hosts share the defect or that the newer beta has fixed it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions