scheduler: ~/Library/Logs/onebrain disappears — twice now, cause unknown

[kengio]

~/Library/Logs/onebrain has now gone missing twice on the same machine. Each time, every registered launchd job is left unable to start: launchd opens StandardOutPath before exec and does not create parents, so all five entries would die with EX_CONFIG 78 writing zero bytes.

Occurrences

1. ~2026-07-30 — the original incident. Symptom was a morning digest that never arrived. Proved by onebrain-search-reindex going 78 → 0 on mkdir -p alone, nothing else changed. Tracked as scheduler: if the log dir is removed after register, every job fails with EX_CONFIG 78 forever — silently #362, which added the scheduler-log-dir doctor check.
2. 2026-07-31 ~23:46 — found again while verifying the scheduler: a skill run can exit EX_CONFIG 78 with a zero-byte stderr — nothing records why #363 check against the real vault. All five jobs would have failed at their next fire (digest at 08:30). Recreated by hand; both scheduler checks green afterwards.

What is established

• The CLI does not delete it. No remove_dir/remove_dir_all exists anywhere in crates/onebrain-core/src/scheduler/ or register_schedule.rs, and nothing destructive references log_base_path. Ruled out by grep, not by assumption.
• Neighbouring directories survive. ~/Library/Logs/ still holds Baseband, Claude, com.apple.CloudTelemetry, com.openai.codex, mole, OneDrive — so this is not a blanket wipe of ~/Library/Logs.
• It is empty when recreated and jobs then work, so nothing depends on prior contents.

What is NOT established

Who removes it. Candidates, none confirmed:

• a third-party disk-cleanup tool (a mole log directory is present on this machine, and "clean up empty/large log dirs" is exactly what such tools do)
• macOS periodic maintenance
• a manual cleanup by the operator that also swept it

The directory is empty in normal operation — launchd only writes to files inside it when a job produces output, and the vault-side audit log is where real output goes. An empty directory is precisely what a cleaner reclaims.

Why this needs more than the existing checks

scheduler-log-dir (#362) and scheduler-silent-runs (#363) both detect the condition, and #362 can even fix it with doctor --fix. Neither prevents it. Between two doctor runs the schedule is silently dead, and the observed gap was over a day.

Options worth weighing

• Keep a sentinel file inside the directory (e.g. .keep), so a cleaner that only reclaims empty directories leaves it alone. Cheap; does not defend against a cleaner that ignores contents.
• Re-assert the directory at fire time — impossible for the launchd failure by construction (the CLI is never reached), but it would cover the systemd and Task Scheduler paths.
• Move the machine-local log destination inside the vault, where the user's own backup/sync covers it. Rejected before as Scheduler logs live in the iCloud-synced vault, so launchd can't open them and every job dies silently #315 (raw process stdout should stay OUT of the vault) — noting it only to record that it was considered and why it was refused.
• schedule register already re-creates it via ensure_log_dir, so re-registering is the practical manual remedy today; worth documenting as such.

Filed from the v3.4.22 epic, where the detection half shipped. This is the prevention half.

[kengio]

iCloud is ruled out as the cause

Verified on the affected machine 2026-08-03:

• The vault has been moved off iCloud — /Users/keng/onebrain/ob-1 is a plain local directory, not under ~/Library/Mobile Documents or ~/Library/CloudStorage, and not a git checkout.
• xattr on a vault file shows only com.apple.provenance — no com.apple.decmpfs, the mechanism confirmed in Scheduler logs live in the iCloud-synced vault, so launchd can't open them and every job dies silently #315.
• The directory that vanishes (~/Library/Logs/onebrain) is machine-local and was never synced in the first place.

So whatever removes this directory, it is not iCloud and not the #315 compression mechanism. One candidate eliminated.

v3.4.23 makes the cause moot, and does not find it

The v3.4.23 design takes the pre-exec redirect off the critical path entirely: stdout → /dev/null, a bootstrap-only stderr channel, and the CLI opening its own log after exec (where it can mkdir, fall back, and report). A vanishing log directory then cannot stop a job from running.

This issue stays open for the cause. The fix removes the consequence, not the phenomenon — a directory disappearing from ~/Library/Logs without explanation is still worth understanding, and it may not be the only thing that vanishes.