I diagnosed two separate ADE issues. **Issue 1: Native iOS stream is marked ready but dra…

[arul28]

Description

I diagnosed two separate ADE issues.

Issue 1: Native iOS stream is marked ready but drawer does not attach as a client

Environment:

• ADE CLI via desktop socket
• Device: iPhone 17 Pro, UDID 95F41FEE-EA2F-4E4B-AF2B-1FC974ABE0AE
• Runtime: iOS 26.2
• App: com.arul.pearl
• Native backend: iosurface-indigo

Evidence:

• ade --socket ios-sim status --json reports iosurface_indigo.available = true.
• ade --socket ios-sim snapshot --text works: screenshot provider is ok.
• ade --socket ios-sim live-start --fps 30 --json starts successfully:
  • running: true
  • backend: iosurface-indigo
  • streamUrl: http://127.0.0.1:63813/ios-simulator/stream.mjpg
• Direct curl to that streamUrl receives valid MJPEG bytes:
  • about 137K
  • multipart boundary --ade-ios-simulator-frame
  • Content-Type: image/jpeg
• After ~30 seconds:
  • running: false
  • lastError: "IOSurface helper stopped after 30s with no active stream clients or input."

This points to a drawer/client bug, not an app or simulator bug. The native stream helper starts and can serve a JPEG frame, but ADE’s drawer is apparently not connecting to, or not holding open, the stream client.

Important comparison:

• ade --socket ios-sim preview-start --fps 2 --text using simctl-screenshot-poll keeps producing frames continuously.
• It reached frames: 151 before I stopped it.
• So screenshot capture and fallback streaming are healthy. The broken path is specifically native IOSurface streaming plus drawer client lifecycle.

Issue 2: Launch target discovery/dropdown behavior is confusing

Observed:

• Launching a built .app directly can launch the app, but did not make the drawer’s manual app dropdown useful.
• Launching by project/scheme worked better:

ade --socket ios-sim launch \
  --project Pearl.xcodeproj \
  --scheme Pearl \
  --udid 95F41FEE-EA2F-4E4B-AF2B-1FC974ABE0AE \
  --project-root /Users/arul/Pearl \
  --mode live \
  --text

After that, activeSession was correctly set to Pearl. But apps --device still surfaced Pearl mainly as a built DerivedData target, not as a clear project/scheme target. For a user, this looks like “No launchable app found” until ADE has built/cached something.

Issue 3: Permission prompts despite “full access mode”

This is separate from iOS sim. The Codex runtime in this session is enforcing workspace-write, not full access. That is why ADE socket access and Xcode/CoreSimulator access triggered permission prompts.

Likely report wording:

ADE UI/session appears to advertise full access, but the Codex subprocess receives/enforces workspace-write, causing require_escalated prompts for ADE socket and simulator/Xcode operations. Prior ADE Codex integration notes suggest sandbox/approval policy propagation has been fragile across thread/start, thread/resume, and turn/start.

Root Cause Hypothesis

1. Native stream bug: ADE drawer is not attaching to the iosurface-indigo MJPEG stream URL, or closes the client immediately, so the helper exits after the no-client timeout.
2. Launch target UX bug: drawer target discovery does not reliably show project/scheme launchables for a new greenfield Xcode project until ADE has built/cached the app.
3. Permission bug: ADE full-access UI state is not being propagated into the actual Codex runtime sandbox/approval policy.

I stopped the diagnostic polling stream I started. I did not change app code during this diagnosis.

Steps to Reproduce

Not provided.

Expected Behavior

Not provided.

Actual Behavior

Not provided.

Environment

ADE version: 1.1.10
Platform: darwin arm64
Electron: 40.8.2
Project: Pearl
Project base ref: main
Selected lane: Primary
Lane branch: arul_iter0
Lane base ref: main
Lane status: clean worktree
HEAD commit: acfe014 Initial commit

[arul28]

[arul28]

I found a much stronger root cause now: ADE’s renderer CSP is blocking the drawer from connecting to the stream URL.

Key evidence:

• ade --socket ios-sim stream-status --text initially showed:

running        no
frames         0
input backend  indigo

• ADE status showed an inconsistent stale state:

active device  iPhone 17 Pro (Shutdown)
active app     com.arul.pearl
mode           live

• Starting native stream while the device was shutdown produced a degraded stream state:

"fallbackReason": "Using simctl-screenshot-poll fallback because [sim-capture] {\"type\":\"no-booted-device\"...}"
"lastError": "xcrun simctl io ... screenshot ... Error creating the image"

• Then launch by project/scheme hung and eventually failed:

Simulator iPhone 17 Pro did not become ready within 90s.
CoreSimulator may be stuck; shut down that simulator and launch again.

But the most important log is in:

/Users/arul/Library/Application Support/ade-desktop/ade-idle.jsonl

Repeated renderer console errors:

Connecting to 'http://127.0.0.1:<port>/ios-simulator/stream.mjpg' violates Content Security Policy: connect-src 'self' file: app: https:
Fetch API cannot load ... Refused to connect because it violates the document's Content Security Policy.
sourceId: file:///Applications/ADE.app/.../AgentChatPane-BBSpXfKG.js

That explains the whole native stream symptom cleanly:

1. ADE starts iosurface-indigo.
2. It exposes http://127.0.0.1:<port>/ios-simulator/stream.mjpg.
3. The drawer renderer tries to fetch it.
4. Electron/CSP blocks the fetch because connect-src does not allow http://127.0.0.1:*.
5. Since the drawer never becomes an active stream client, ADE later reports no active stream clients / no frames.

So the primary issue report should say:

ADE iOS Simulator drawer cannot render native stream because the packaged renderer Content Security Policy blocks http://127.0.0.1:<dynamic-port>/ios-simulator/stream.mjpg. The stream backend starts, and the MJPEG endpoint can serve frames, but the drawer fetch is blocked by connect-src 'self' file: app: https:. Add http://127.0.0.1:* / localhost stream origin to the renderer CSP or proxy the stream through an allowed app:/same-origin route.

Secondary issues:

• ADE can show live app/session state while the selected simulator is actually shutdown.
• live-start can degrade to screenshot-poll with no-booted-device but still report a stream URL/running state briefly.
• launch --project --scheme can time out after 90s saying simulator not ready even while simctl and ade status show the device booted.
• activeSession can be created during that launch attempt, then later cleared after timeout.

I stopped/cleared the diagnostic simulator session afterward; shutdown reported released no, meaning there was no active session left to release.