[Bug]: Expo Device Hub retains simulator capture sessions without clients and uses ~200% CPU

[PrinceJunkie]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

The original trigger has not been reproduced from a fresh launch. This sequence follows the affected session history:

1. Run T3 Code Alpha 0.0.45 on Apple Silicon with its pinned Expo Device Hub 0.12.0.
2. Have an agent open iOS simulator previews. The affected hub retained two simulator capture sessions.
3. Leave the simulators booted, close or leave the previews, and continue using T3 Code.
4. After extended use, inspect the Expo Device Hub child process rather than only the desktop renderer.
5. Check whether capture counters continue advancing and CPU stays high after all preview clients disconnect.

An agent used a device preview earlier in my session. Overall application activity when I first noticed the issue is uncertain. During inspection, the selected chat was paused and displayed a file panel instead of a device preview. The hub had been running for about 12 hours; this is process uptime, not the measured duration of high CPU usage.

Expected behavior

Native device capture and its timers should stop or suspend when the last preview consumer leaves, and restart when needed. The hub should consume little CPU when no preview clients are connected.

Actual behavior

The CPU consumer is T3 Code's bundled Expo Device Hub, running under the Electron executable in Node mode. Seven observations over approximately 31 seconds (00:32:48–00:33:19 CEST) measured 184.7–198.9% CPU, averaging 192.8%. On macOS, 100% is one CPU core. The hub accumulated about 60 seconds of CPU time in this window.

Process	PID	CPU range	Mean CPU
Expo Device Hub	5673	184.7–198.9%	192.8%
T3 desktop main	18553	0.0–0.1%	0.03%
T3 server	18637	0.1–0.4%	0.20%
Main renderer	18636	0.0–0.3%	0.17%
GPU helper	18556	0.4–0.7%	0.54%
Agent Device daemon	5790	0.0%	0.0%

Repeated lsof observations showed only a listening TCP socket on 127.0.0.1:53853, with no established connections. The hub had two existing simulator state records; both capture statistics reported zero WebRTC sessions. A later snapshot at 00:36:40 showed 120.8% CPU, still with no connections, so the load fluctuates.

Reads of the existing sessions' /webrtc/stats endpoints at 00:34:42 and 00:34:48 showed continued work without new frames:

Capture session	Additional poll ticks and surface selections	Surface selection time	Mean per selection	New screen or idle frames
Simulator 1	14	4,220.62 ms	301.47 ms	0
Simulator 2	13	4,387.80 ms	337.52 ms	0

This stats endpoint uses peekDeviceSession, so these reads do not create capture sessions. Resident memory was 568–586 MiB; macOS stack samples reported a physical footprint of 1.3 GB (a different memory measure).

Two native stack samples (10 s and 5 s) show the same busy ROCKit remote-proxy paths, map enumeration, weak-reference handling, and two frame-capture queues releasing blocks/autorelease pools. Two worker threads were observed at approximately 95% CPU each. The JavaScript main thread was predominantly waiting in uv__io_poll → kevent.

Likely lifecycle problem: the installed bundle's getDeviceSession starts and retains the primary capture session until closeDeviceSession. MJPEG/AVCC disconnect handlers unsubscribe their stream consumers but do not close that session. The associated native code starts a strict 60 Hz framebuffer polling timer; stop() cancels it and unregisters callbacks. T3's LocalDeviceHost retains and supervises the hub process.

Relevant source revision from expo-device-hub 0.12.0's published gitHead:

• DeviceSession lifecycle
• Native polling and shutdown

Continued capture with no preview clients is confirmed. Accumulated proxies, stale descriptors, or native cleanup failure could explain the expensive surface lookups; a specific memory leak is not established. Please investigate capture shutdown when the last consumer leaves and why surface lookups retry indefinitely without producing frames. The attached archive includes the detailed report, sanitized full native samples, raw CPU observations, capture counters, and the confirmed shutdown check.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Alpha 0.0.45; pinned expo-device-hub 0.12.0; agent-device 0.21.12

Environment

macOS 26.7.1 (25G241), MacBook Pro Mac14,9, Apple M2 Pro (10 cores), 32 GB RAM, Electron 44.4.2, Xcode 27.0 (27A266a), iOS 27.0 simulator runtime. Observed 2026-10-07 around 00:29–00:40 CEST.

Logs or stack traces

Process tree:
T3 Code desktop (PID 18553)
  T3 Code server, apps/server/dist/bin.mjs (PID 18637)
    Expo Device Hub (PID 5673)

Hub command:
/Applications/T3 Code (Alpha).app/Contents/MacOS/T3 Code (Alpha)
  /Users/USER/.t3/tools/expo-device-hub/0.12.0/node_modules/expo-device-hub/dist/server/cli.mjs
  --port 53853 --host 127.0.0.1 --hide-sidebar --hide-boot-device

Busy native stack:
serve-sim-native.node
  ROCKRemoteProxy._forwardStackInvocation
  rock_ROCKInvocationInterfaceInvokeWithRemoteProxy
  rock_NSBlockToXPCObject
  ROCKForwardingBlockProxy.forwardingProxyWithSessionManager
  rock_ROCKSessionManagerForwardingProxyForInstance
  NSEnumerateMapTable
  NSConcreteMapTable.getKeys:values:
  objc_loadWeakRetained / weak_entry_for_referent

Both native samples also show two frame-capture queues spending substantial time
releasing Objective-C blocks and draining autorelease pools. The full sanitized
samples retain native addon binary offsets for symbolication.

Screenshots, recordings, or supporting files

t3-code-cpu-diagnostics.zip

Workaround

Fully quitting T3 Code stopped the CPU-heavy hub. At 00:40:19 CEST, the desktop, server, hub PID 5673, renderer/helpers, resource monitor, and Agent Device daemon had exited, and nothing was listening on the hub's former port 53853. Recurrence after relaunch remains unverified. Killing only the hub may cause T3's supervisor to restart it.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Confirmed on current main with pinned expo-device-hub@0.12.0 (DEVICE_HUB_VERSION in DeviceToolchain.ts). The hub is a long-lived supervised child; preview disconnect alone does not stop native simulator capture, which matches the ~185–200% CPU / ongoing surface-selection polls with zero clients.

What T3 owns today

• LocalDeviceHost starts and supervises the hub for the server’s lifetime. Idle preview clients do not stop or recycle that process (by design — crash isolation from CoreSimulator).
• DeviceHubProxy only proxies allowlisted stream/HTTP/WebSocket routes. When the last client drops, the proxied connection tears down; nothing calls a hub “close capture session” API.
• DeviceService.close removes T3’s own session records. It only hits serve-sim’s capture shutdown as part of device power-off (…/grid/api/shutdown on iOS). Leaving the simulator booted after closing a preview therefore leaves the hub’s in-process capture alone.
• The viewer explicitly primes iOS capture by briefly hitting stream.mjpeg before AVCC (primeIosHelper in packages/client-runtime/src/device/stream.ts). That starts the native 60 Hz path; aborting the client stream does not reverse it.

Likely hub lifecycle gap (agrees with your report)

In expo-device-hub 0.12.0, getDeviceSession retains the primary capture until closeDeviceSession. MJPEG/AVCC disconnect handlers unsubscribe consumers without closing that session, so FrameCapture’s polling timer keeps running. Your /webrtc/stats ticks (~300 ms surface selections, 0 new frames) and ROCKit/frame-capture stacks fit that retained session with no consumers. Fully quitting T3 stops it because the supervised hub exits.

Fix direction

1. Upstream / pin: hub should stop (or suspend) native capture when the last stream consumer leaves, and/or expose a reliable close-session that T3 can call without simctl shutdown.
2. T3 mitigation: on last preview disconnect (or after a short idle), call that close (or recycle the hub) without powering off the simulator — today there is no such path. #12639 only fixed shutdown leaving a cached capture across reboot; it does not cover “simulator still booted, no viewers.”

Not duplicates

• Merged #12639 — recover streams / iOS shutdown cache.
• Open #12765 — physical Android streaming.

No open fix PR for this idle-capture CPU leak. Workaround of fully quitting T3 is correct; killing only the hub may just get it respawned by the supervisor.

Labeling bug + via-triage.

[Mixer159]

Another reproduction, with one difference from the original report: no simulator was booted.

Setup: macOS 27.0 (26A428), M1 Pro, 16 GB. T3 Code Nightly 0.0.46-nightly.20261005.2702 with the pinned expo-device-hub@0.12.0. Device support and agent device access are on.

Hub child process (expo-device-hub/.../dist/server/cli.mjs --hide-sidebar --hide-boot-device):

• Up 24 h 49 min with 20 h 32 min of CPU time (about 83% of a core on average), 96 to 99% each time I sampled it, 1.2 GB physical footprint.
• xcrun simctl list devices booted: none.
• lsof -iTCP on the hub: only its LISTEN socket, no established connections.
• sample puts the CPU in two places:
  • the frame-capture serial queue: dispatch timer → serve-sim-native.node → -[ROCKRemoteProxy _forwardStackInvocation:], mostly in objc_autoreleasePoolPop / _Block_release
  • ROCKSessionManager.instancesQueue threads, mostly in -[NSConcreteMapTable getKeys:values:] → weak_entry_for_referent

The second stack looks like ROCKit's session map growing with each capture tick, which would explain CPU climbing over hours instead of being high from the start. I didn't measure the growth directly; it's an inference from the stacks and from the lifetime average being below the sampled rate.

SIGTERM to the hub fixed it immediately. T3 respawned a fresh hub that sat at 0.0% CPU with no clients.

I don't know how the simulator was shut down (T3's device panel, Xcode or simctl). Either way the capture outlived the simulator, so closing the session only on T3's power-off path may not be enough. It probably also needs to close when the simulator goes away or the last consumer leaves.

Workaround until this lands, in case it helps anyone: a launchd job every 5 minutes that sends SIGTERM to the hub when it stays above 60% CPU for two checks in a row with no established TCP connections.