macOS supervisor cannot start with bootstrap logs on an affected external volume

With OCM_HOME on an external SSD, the macOS OCM background service failed before starting the supervisor: launchd reported exit 78 / EX_CONFIG. Foreground execution of the isolated gateway worked. Moving only the LaunchAgent's StandardOutPath and StandardErrorPath to an internal-disk directory allowed the same supervisor to start.

Observed with OCM 0.2.38 on macOS 26.6.2. Current main is c5e7126c9b6cf7fb9b6f7903f59393f95e4c6ef1; its daemon log-path construction is unchanged.

Reproduction conditions and evidence

Use a disposable OCM store on a mounted external volume, with a valid isolated environment/runtime. Install/start its managed gateway through OCM. On the affected host, the generated LaunchAgent placed both bootstrap streams below $OCM_HOME/supervisor/logs; launchd failed to start the supervisor.

In a controlled diagnostic, only those two plist paths were moved to a writable internal-disk log directory. The executable, OCM_HOME, working directory, environment/runtime data and gateway logs stayed in their original locations. No macOS privacy permission was changed. After reloading that definition, the supervisor started and the gateway eventually passed health and catalog checks.

This is a version-pinned runtime observation, not a claim that every external disk fails. The exact macOS access-policy mechanism remains unproven. The later gateway readiness delay is not attributed to this startup-path defect.

Missing supported recovery path

Expected: an operator can select an accessible bootstrap-log destination without moving the OCM store or editing a generated plist. Actual: both paths are tied to the store, leaving the affected setup unable to start through the generated definition. The expected recovery control is a proposed capability, not an existing documented setting.

supervisor_daemon_definition in src/supervisor/mod.rs derives both bootstrap paths from supervisor_logs_dir, which is fixed beneath the store. There is no separate supported bootstrap-log location. Hand-editing the plist is fragile because a subsequent OCM definition regeneration can overwrite it.

A supported way to place just the supervisor bootstrap logs on an accessible local filesystem would let operators preserve external storage for state and runtimes. An opt-in location would preserve today's default; an automatic macOS-specific location would need a documented compatibility decision. Neither should silently move environment data or gateway logs, grant privacy permissions, or weaken service ownership.

Acceptance: generated definitions and reported daemon log paths agree; the destination is prepared with appropriate permissions; regeneration retains the chosen location; gateway logs and store paths stay unchanged; and a native external-volume before/after check demonstrates startup on an affected host.

Candidate and remaining decision

Draft PR #150 provides an opt-in environment-variable candidate. It has passing regression and cross-platform CI, but requires the variable on subsequent CLI calls: it does not persist the choice per store. Maintainers still need to decide whether that contract is sufficient or a durable setting is required. The affected-host patched startup check is also outstanding. Neither this candidate nor the separate plist ownership repair in PR #149 closes this report yet.

Start with supervisor_daemon_definition in src/supervisor/mod.rs and review Draft PR #150's environment-variable candidate. Compare the generated definition and reported daemon log paths with the acceptance criteria, including regeneration and permissions. Done requires a decided persistence contract and a native affected-host before/after startup check without changing store or gateway-log locations.