When the app launches, any initial UI content (loading screen, app chrome) that doesn't contain a target label causes promptsDismissed = true to be set immediately, skipping all prompt dismissals even though the actual first-run prompts haven't appeared yet.

Also found at:

• src/benchmarks/claude-ui/simulator-lifecycle.ts:256-259

If appendLifecycleLog fails (e.g. disk full, bad log path), .catch(reject) surfaces the I/O error instead of resolving with the already-complete result, silently dropping the command's exit code, stdout, and stderr.

In simulator-lifecycle.ts, the close handler calls resolve(result) only inside .then() of the appendLifecycleLog promise, so any transient I/O error writing the lifecycle log (e.g. disk-full) causes the outer promise to reject with a log error instead of resolving with the command result — making prepareTemporarySimulator throw as if xcrun simctl boot or bootstatus failed when they actually succeeded.

writeMcpConfig in harness.ts calls mkdir/writeFile directly from node:fs/promises with no filesystem injection, so the corresponding tests in simulator-lifecycle.test.ts resort to real mkdtemp(os.tmpdir(), ...) plus real readFile to verify output. This is sandboxed and deterministic (no xcodebuild/xcrun/AXe/device/simulator calls), but it does deviate from the skill's preference for injecting filesystem dependencies. Consider extracting the pure config-building logic (already mostly isolated in isolatedSessionDefaults) and testing that without I/O, or threading a writer abstraction into writeMcpConfig.

If the spawned process (e.g. claude) exits before consuming all stdin, child.stdin will emit an 'error' event (EPIPE) with no registered listener, which becomes an uncaught exception and crashes the benchmark process.

In runCommand, the createWriteStream instances for stdout/stderr have no 'error' listener attached before being used as pipe destinations. If a write fails (e.g. disk full, permission error on the artifacts directory) before child.on('close', ...) fires, Node will emit 'error' on a stream with no listener and throw an uncaught exception, crashing the benchmark run. child.on('error', reject) only covers spawn errors, and finished(stdout)/finished(stderr) is only awaited inside the close handler. This is local-only benchmark code so user impact is limited to a noisy crash during a benchmark run rather than a clean rejection, but adding .on('error', reject) to both streams is a small, safe hardening.