[GH-ISSUE #4084] [Question] Supported macOS sandbox configuration for read-only process inspection in static analysis #1613

New issue

Open

opened 2026-10-16 21:07:59 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:07:59 +00:00

Owner

Originally created by @danyu095-ui on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4084

We are validating static JavaScript analysis on macOS using rea-agents-6.5.0, commit 3b79af28e8.

Dependency installation, build, and CLI help succeed. In our execution context, the Swift driver initially terminated with SIGTRAP; selecting the compatibility driver via SWIFT_USE_OLD_DRIVER=1 allowed an inert synthetic fixture to be parsed. We do not have enough crash evidence to establish the original Swift root cause. Analysis still finishes unsuccessfully with process inspection reporting spawn EPERM / cleanup_incomplete. We have not treated partial parsing as a successful run or disabled ownership checks.

We read #2290 and #2321. Our current source and reachable compiled code contain the equivalent bounded-exit handling, so this is not a request to reapply the CLI hang fix. We also see the explicit successful-control exception documented in #2290:

(allow process-exec (literal "/bin/ps") (with no-sandbox))

Before changing our isolation configuration, could you clarify:

Is this exact exception a supported configuration for static analysis, or only a diagnostic control? Is there a recommended complete profile and launch command preserving the source-analysis worker's filesystem and network restrictions?
What is the intended inheritance scope of this exception? Does only the /bin/ps inspector escape this layer, and are there caveats with an additional sandbox imposed by the launching host?
Is reading the system-visible process table, including command arguments, a mandatory current prerequisite? Is there an officially supported narrower inspector configuration that preserves descendant ownership verification and safe cleanup?
What successful exit and cleanup evidence should callers use to qualify this setup before analysing real source repositories?

We are not requesting a workaround that bypasses host restrictions, removes ownership verification, or signals processes with uncertain identity. We would like a reproducible supported configuration, or a clear statement that this host configuration is currently unsupported.

This report intentionally contains no project source, private filesystem paths, credentials, process listings, or customer data. Thank you.

Originally created by @danyu095-ui on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4084 We are validating static JavaScript analysis on macOS using rea-agents-6.5.0, commit 3b79af28e80785afce9f5998d8f03289402a1847. Dependency installation, build, and CLI help succeed. In our execution context, the Swift driver initially terminated with SIGTRAP; selecting the compatibility driver via SWIFT_USE_OLD_DRIVER=1 allowed an inert synthetic fixture to be parsed. We do not have enough crash evidence to establish the original Swift root cause. Analysis still finishes unsuccessfully with process inspection reporting spawn EPERM / cleanup_incomplete. We have not treated partial parsing as a successful run or disabled ownership checks. We read #2290 and #2321. Our current source and reachable compiled code contain the equivalent bounded-exit handling, so this is not a request to reapply the CLI hang fix. We also see the explicit successful-control exception documented in #2290: `(allow process-exec (literal "/bin/ps") (with no-sandbox))` Before changing our isolation configuration, could you clarify: 1. Is this exact exception a supported configuration for static analysis, or only a diagnostic control? Is there a recommended complete profile and launch command preserving the source-analysis worker's filesystem and network restrictions? 2. What is the intended inheritance scope of this exception? Does only the /bin/ps inspector escape this layer, and are there caveats with an additional sandbox imposed by the launching host? 3. Is reading the system-visible process table, including command arguments, a mandatory current prerequisite? Is there an officially supported narrower inspector configuration that preserves descendant ownership verification and safe cleanup? 4. What successful exit and cleanup evidence should callers use to qualify this setup before analysing real source repositories? We are not requesting a workaround that bypasses host restrictions, removes ownership verification, or signals processes with uncertain identity. We would like a reproducible supported configuration, or a clear statement that this host configuration is currently unsupported. This report intentionally contains no project source, private filesystem paths, credentials, process listings, or customer data. Thank you.

bsakaguchi commented

2026-10-31 00:31:49 +00:00

Author

Owner

@max-gaevoy commented on GitHub (Oct 28, 2026):

Adding a reproduction with REA 6.8.0:

macOS 27.2, arm64
Node.js 24.22.1
Locally installed rea-agents 6.8.0
Isolated static JavaScript analysis of an inert synthetic fixture, not a real application or private repository

The analyzer found relationships in the fixture, but the CLI exited with code 1 and cleanupIncomplete. Process inspection failed with spawn EPERM for:

ps -axo pid=,ppid=,pgid=,uid=,stat=,command=

A subsequent signal-0 check of the worker PID returned ESRCH. Descendant absence was not verified, so we do not consider cleanup complete or the run successful.

We read the 6.8.0 process-capture documentation and #2290 / #2321. The CLI now exits rather than hanging; our remaining blocker is the process-inspection prerequisite. We have not disabled ownership checks, changed sandbox permissions, or enabled MCP as a workaround.

Is there a documented, supported way to complete static JavaScript analysis and verify descendant cleanup in this restricted macOS context without weakening the sandbox? If not, could you confirm that this context is currently unsupported and identify the required supported environment or a tracked narrower-inspector implementation?

We are not requesting an exception that bypasses host restrictions, treating a missing worker PID as proof of full cleanup, or signalling processes with uncertain ownership.

@max-gaevoy commented on GitHub (Oct 28, 2026): Adding a reproduction with REA 6.8.0: - macOS 27.2, arm64 - Node.js 24.22.1 - Locally installed rea-agents 6.8.0 - Isolated static JavaScript analysis of an inert synthetic fixture, not a real application or private repository The analyzer found relationships in the fixture, but the CLI exited with code 1 and `cleanupIncomplete`. Process inspection failed with `spawn EPERM` for: ```text ps -axo pid=,ppid=,pgid=,uid=,stat=,command= ``` A subsequent signal-0 check of the worker PID returned ESRCH. Descendant absence was not verified, so we do not consider cleanup complete or the run successful. We read the 6.8.0 process-capture documentation and #2290 / #2321. The CLI now exits rather than hanging; our remaining blocker is the process-inspection prerequisite. We have not disabled ownership checks, changed sandbox permissions, or enabled MCP as a workaround. Is there a documented, supported way to complete static JavaScript analysis and verify descendant cleanup in this restricted macOS context without weakening the sandbox? If not, could you confirm that this context is currently unsupported and identify the required supported environment or a tracked narrower-inspector implementation? We are not requesting an exception that bypasses host restrictions, treating a missing worker PID as proof of full cleanup, or signalling processes with uncertain ownership.

bsakaguchi referenced this issue

2026-10-31 00:54:08 +00:00

[PR #1613] [MERGED] feat(skills)!: improve Codex onboarding and task recovery #4700

bsakaguchi referenced this issue

2026-10-31 00:54:10 +00:00

[PR #1618] [MERGED] fix(ci): preserve cleanup boundaries and bounded failure assertions #4705

bsakaguchi referenced this issue

2026-11-03 21:43:16 +00:00

[GH-ISSUE #1587] [Feature] Improve task-centered REA onboarding and recovery in Codex skills #535