René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Bug]: Terminal daemon spawns full-table ps scans ~1,000/min on macOS, keeping syspolicyd/EDR busy around the clock","articleBody":"### Operating system\n\nmacOS\n\n### Orca version\n\n1.4.237\n\n### Details\n\n**Short summary:** The terminal daemon (`orca-terminal-host` running `daemon-entry.js`) launches processes continuously, mostly full process-table `ps` scans. On macOS every launch goes through AppleSystemPolicy/syspolicyd, so the steady rate keeps the security stack busy around the clock and floods the unified log. This is a freshly started daemon, not the stale post-update daemon from #23372.\n\n**Environment**\n\n- macOS 27.0.1 (26A434), Apple silicon, 32 GB\n- Orca 1.4.237, daemon protocol v50, started fresh at boot. `lsof` shows no ShipIt mappings, and there is one \"Malware rejection\" line this boot.\n- Microsoft Defender for Endpoint installed (endpoint security and network extensions), so every exec is also inspected by EDR, as in #12398\n\n**What happened**\n\n1. The kernel logs AppleSystemPolicy lines attributed to the daemon image at about 1,000–1,150 per minute. That rate started within a minute of boot, with 3 live PTY sessions:\n   ```\n   kernel (AppleSystemPolicy) ASP: Unable to apply provenance sandbox: 268451845, 90900, ~/Library/Application Support/orca/daemon-host/macos/terminal-host-\u003chash>/app.noindex/Orca Terminal Host.app/Contents/MacOS/orca-terminal-host\n   kernel (AppleSystemPolicy) ASP: Unable to apply provenance sandbox: 268451845, 90901, ...\n   kernel (AppleSystemPolicy) ASP: Unable to apply provenance sandbox: 268451845, 90902, ...\n   ```\n   The pid increments by one roughly every millisecond within a burst.\n2. During the previous boot, hourly counts of that line ranged from 25,000 to 81,000 between 14:00 and 22:00, which is about 7–22 per second.\n3. syspolicyd logged roughly 150,000 `Unable to initialize qtn_proc` and `dispatch_mig_server returned` errors in a two-hour window of that boot.\n4. Sampling the daemon's children (`pgrep -P \u003cdaemon pid>` in a loop for 10 seconds) found 18 children: 6 were still readable as\n   ```\n   ps -axo pid=,ppid=,pgid=,tpgid=,stat=,tdev=,lstart=,command=\n   ```\n   9 had exited before their arguments could be read, and 3 were the PTY login shells. Sampling misses short-lived processes, so this is a lower bound on the `ps` rate.\n\n**User-visible impact (correlated, not proven causal):** starting and closing sessions gets slower the longer the machine is up, and the daemon log has 9 `shell-ready-timeout` events (15 s) over the past month. The log churn also rotates unified logs fast enough that evidence from previous days is gone.\n\n**How to reproduce**\n\n1. Boot a Mac running macOS 27 and launch Orca 1.4.237 with a few terminals open.\n2. Run `/usr/bin/log stream --predicate 'process == \"kernel\" AND eventMessage CONTAINS \"orca-terminal-host\"'` and watch the rate.\n3. Optionally run `pgrep -P \"$(pgrep -f daemon-entry.js)\"` in a tight loop to see the `ps -axo ...` children.\n\n**Suggestions**\n\n- Lower the polling frequency, or poll only when a session is starting or exiting.\n- Use `libproc` / `sysctl(KERN_PROC)` from the daemon to read process state instead of launching `ps`. That removes the exec, the syspolicyd assessment and the EDR inspection.\n- If polling has to stay, scope it to the daemon's own process groups instead of scanning the whole table with `-ax`.\n\nRelated: #12398 (Helper `ps` polling amplified by EDR, closed), #23372 (stale daemon spawn storm after auto-update).\n","author":{"url":"https://github.com/steveermish","@type":"Person","name":"steveermish"},"datePublished":"2026-10-22T02:37:10Z","url":"https://github.com/stablyai/orca/issues/31783"}