[ymote]

On macOS main (7abf34d) the Terminal, a native module hosted as a process on the desktop, crashes at start: Terminal exited before opening a window (signal: 11 (SIGSEGV)). There are 5 crash reports, all in MTLCreateSystemDefaultDevice → IOSurface → CFBundleCopyBundleURL (null bundle).

Cause. G6 (#156) closes the OctoSense home last in the process sandbox. Desktop builds put process apps' programs in <OctoSense home>/build, so the private deny (last match wins) takes away the Terminal's read access to its own program and bundle.

Reproduced with the generated profile: sandbox-exec -f <profile> terminal exits 139. With the program re-allowed after the private rules, it passes Metal init and exits 0 (no hub in the test).

Fix:

• macOS: after the private deny and the app's own jail, re-allow read-only the program paths that lie inside a private directory.
• Linux (Landlock): program rules are no longer dropped inside private directories; the same bug would hit a program under the OctoSense home.
• Test: a_program_inside_the_octosense_home_stays_readable checks that the program is readable after the deny, is never writable, and that nothing else is reopened.

Local checks: cargo test --locked --features mobile-apps -p octosense-shell sandbox: 12 passed, including the real macOS sandbox test home_rw_never_reaches_the_octosense_home_or_the_kernel.

🤖 Generated with Claude Code

[ymote]

I reviewed this (I wrote the G6 code). The diagnosis is right and the fix is right in shape: reopen the program read-only after the private deny, and on Linux keep program rules in around_private. Please add one guard before merging.

Guard: never reopen a program path that equals or contains a private-sensitive dir.

• Policy::program also holds "the checkout it was built from" and cargo's source cache. Nothing currently stops an entry from being broad.
• For example, a dev setup that points the checkout or CARGO_TARGET_DIR at ~/.octosense itself (or at ~/.octosense/..) would reopen the whole OctoSense home read-only: peer host tokens, other apps' secrets, kernel data. That's the exact thing G6 closes.
• The filter only checks p.starts_with(root) ("inside a private dir"). A path that equals a private root passes it too.

Suggested rule, the same on both platforms:

• only reopen a program path strictly inside a private root;
• skip it (and log) if it equals a private root, or if any of these is at or under it: the apps root, the secrets root, the kernel's core dir, or the peers/profile dirs.

Tests to add:

• a program equal to the OctoSense home is not reopened;
• a program at <home>/.octosense/build/x is reopened, but <home>/.octosense/secrets stays denied (assert that no allow after the deny covers secrets/ or apps/).

Linux. policy.program.contains(&rule.path) keeps the program rule with whatever rights rules() gave it. Please confirm those are read (plus execute), never write, since the macOS side is explicitly read-only. The same guard applies there.

Minor: the new test builds the path from home_rw_with_octosense_home. A comment naming which private roots that helper sets would make the "nothing else reopened" assertion easier to follow.

Otherwise LGTM. The rest can merge once CI passes and the guard is in.

🤖 Generated with Claude Code

[ymote]

Re-reviewed at 3619f0d. program_reopenable covers the cases I raised: strictly inside a private root; not equal to or containing a private dir; not inside apps/secrets/core or the kernel's .octos home; not under app-peers. Linux masks the kept rule to read+execute. One thing to keep: both sides of the comparison must be resolved paths (symlinks), as private is. If program entries aren't resolved the same way, a symlinked checkout could bypass the check, so please confirm they go through the same resolved(). LGTM once CI is green.

🤖 Generated with Claude Code