Separate GUI sessions per runner

[Peyton-Spencer]

Summary

Currently, all runners share the same GUI session (user's desktop). For full isolation, each runner should get its own dedicated GUI session.

Current Behavior

When --enable-gui is used, runners can access the display but share the same session:

• Multiple runners can interfere with each other's GUI operations
• Windows from different runners appear on the same desktop
• No true visual isolation

Desired Behavior

Each runner with GUI access should run in a separate GUI session:

• User isolation mode: Use launchctl bootstrap gui/{uid} to create per-user GUI contexts
• Container isolation: Each container should have its own virtual display

Benefits

• True visual isolation between runners
• Prevents GUI interference (window focus stealing, etc.)
• Better for parallel E2E tests
• Cleaner architecture

Implementation Notes

For user isolation:

# Create GUI session for dedicated user
launchctl bootstrap gui/$(id -u _macrunner) /path/to/plist

For container isolation:

• May need Xvfb or similar virtual display inside containers
• Or use macOS's native per-user GUI sessions if available in containers

References

• Related to headless mode feature (feat/headless-default branch)
• macOS launchctl GUI sessions: man launchctl
• Xvfb (X Virtual Framebuffer) for Linux containers

Priority

Medium — headless mode addresses the main use case. This is for advanced parallel visual testing scenarios.

[Peyton-Spencer]

Related: PR #28 Headless Mode May Address Core Use Case

PR #28 (feat: headless mode) changes the default to headless with opt-in GUI access. This likely resolves the main isolation concern because:

1. Default behavior: No GUI session at all → perfect isolation
2. Opt-in GUI: Only runners that explicitly need GUI get display access
3. Reduced interference: Most runners won't touch the display

Remaining Use Case for Separate Sessions

Separate GUI sessions are still valuable for:

• Parallel visual E2E tests - Multiple runners doing UI automation simultaneously
• Screenshot/video testing - Capturing different test outputs without window conflicts
• VNC-style remote access - Each runner gets its own viewable desktop

Implementation Considerations

If pursuing separate sessions after #28 merges:

macOS Boot Contexts (native approach):

# Each runner gets a unique UID + GUI bootstrap
sudo dscl . -create /Users/_macrunner{N} UniqueID {5000+N}
launchctl bootstrap gui/{5000+N} /path/to/runner.plist

VNC Server per Container (virtualized approach):

# Inside each container, start a VNC server on unique port
container exec <id> vncserver :1 -geometry 1920x1080
# Access via vnc://localhost:590{N}

FastMac Cloud Sessions (macOS-native virtual displays):

• Use macOS's built-in Screen Sharing per-session isolation
• May require Enterprise Device Management (EDM) profiles

---

Recommendation:

1. Merge PR feat: add headless mode (default) with optional GUI access #28 first (headless by default)
2. Re-evaluate this issue based on actual GUI usage patterns
3. Only implement separate sessions if users report visual interference issues

Likely outcome: Most users won't need GUI at all → issue becomes low priority.