fix(system-monitor): prevent overlapping menu-bar collectors

[Olli0103]

Description

The 10-second menu-bar refresh previously entered the full collection path, including nettop and the bundled temperature reader. Those external processes can outlive a refresh and accumulate as zombies, as reported in #30221. A React-local guard also cannot coordinate separate Raycast workers.

This change makes launch behavior explicit:

• Background launches resolve the pinned statistic before collecting.
• CPU and storage use bounded collectors without external programs.
• Memory keeps the Memory tab's macOS accounting. Background launches reuse the last user-collected value or show it as unavailable until the menu is opened.
• Network, temperature, and battery also reuse the last valid cached value or report that no value is available. Background launches never start nettop or temperature-reader.
• An atomic directory lease prevents overlapping background collectors across workers and recovers abandoned leases after 20 seconds.
• One schema-versioned, validated snapshot replaces render-time cache writes. Malformed, incompatible, or oversized entries are ignored.
• User-initiated launches retain the complete dropdown data.

The main System Monitor UI is unchanged. This does not overlap draft PR #30733.

Verification

• npm run validate
  • Raycast lint and Prettier passed
  • 70 tests passed, 1 opt-in endurance test skipped
  • both command entry points built successfully
• npx tsc --noEmit passed
• git diff --check passed

The opt-in soak ran the background path at the real 10-second interval for 60 seconds:

{
  "durationMs": 60000,
  "intervalMs": 10000,
  "launches": 14,
  "maxOverlappingCollectors": 1,
  "nettopCollectorCalls": 0,
  "memoryCollectorCalls": 0,
  "temperatureReaderCollectorCalls": 0,
  "cacheEntryCount": 1,
  "cacheBytes": 1007,
  "collectionDurationMs": { "p50": 0, "p95": 27, "max": 27 }
}

Before the memory-accounting follow-up, an overnight Raycast development run logged more than 2,200 scheduled menu-bar launches. After the initial activation, the background zombie count stayed flat, no external collector remained, the cache stayed bounded, and no lease directory remained.

Remaining evidence

• needs_evidence: 2,880 consecutive refreshes on an awake Mac for the full eight-hour acceptance run. The overnight run contained sleep gaps and does not meet that criterion.
• needs_evidence: Raycast's manual Refresh Menu Bar Item development action created defunct children owned directly by Raycast Backend, while no nettop, temperature reader, or fan reader remained. Scheduled background launches did not increase this count. This should be checked against a release build separately from the background collector fix.

Screencast

Not applicable. This is a process-lifecycle change with no UI changes.

Checklist

• I read the extension guidelines
• I read the documentation about publishing
• I ran npm run build and tested this distribution build in Raycast
• I checked that files in the assets folder are used by the extension itself
• I checked that assets used by the README are placed outside of the metadata folder

Refs #30221

[raycastbot]

Thank you for your contribution! 🎉

🔔 @hossammourad @lucasmezencio @pernielsentikaer @ridemountainpig @xmok @JadenMajid @ADCAdams @TurboCoder13 you might want to have a look.

You can use this guide to learn how to check out the Pull Request locally in order to test it.

📋 Quick checkout commands

BRANCH="ext/raycast-system-monitor"
FORK_URL="https://github.com/Olli0103/raycast-extensions.git"
EXTENSION_NAME="system-monitor"
REPO_NAME="raycast-extensions"

git clone -n --depth=1 --filter=tree:0 -b $BRANCH $FORK_URL
cd $REPO_NAME
git sparse-checkout set --no-cone "extensions/$EXTENSION_NAME"
git checkout
cd "extensions/$EXTENSION_NAME"
npm install && npm run dev

We're currently experiencing a high volume of incoming requests. As a result, the initial review may take up to 15 business days.

[greptile-apps]

Confidence Score: 4/5

The code appears safe, but the changelog rule must be fixed before merge.

Findings

1.  Restore the merge-date placeholder ▶

Fix with agent prompt

### Issue 1
extensions/system-monitor/CHANGELOG.md:3
This entry must keep `{PR_MERGE_DATE}` instead of a fixed date. The merge flow replaces that placeholder with the real merge date. Restore the placeholder to follow the changelog rule.

```suggestion
## [Menu Bar Process Safety] - {PR_MERGE_DATE}
```

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

System Monitor background refreshes now collect only the pinned CPU or storage value, reuse other cached values, and avoid starting external collectors. A shared lease and validated snapshot cache keep separate Raycast workers from overlapping or growing stale cache data.

• Background launches choose a bounded collector based on the pinned statistic.
• Memory, network, temperature, and battery reuse the last user-collected values.
• A 20-second recoverable lease prevents overlapping workers.
• One versioned snapshot cache records validated collection results.

_{Reviews (4) · Last reviewed commit: "Update CHANGELOG.md"}

[pernielsentikaer]

Hi @Olli0103 👋

Thanks for this — the background refresh no longer spawning nettop or temperature-reader, the cross-process lease, and the validated snapshot cache look like a solid fix for the zombie accumulation in #30221, and the regression tests are a nice touch 💪

I found this while reviewing:

collectMemoryUsage in src/menubar/collect-snapshot.ts now backs both the background and the user-opened menu-bar Memory value, but it uses totalmem() - freemem(), while the Memory tab still uses getMemoryStats (app + wired + compressed). On macOS os.freemem() only counts genuinely free pages, so inactive/cached pages are treated as used and the menu-bar Memory reading can sit well above the Memory tab (and above what the menu bar showed before this PR).

Could you keep the menu-bar Memory value consistent with the Memory tab — for example use the existing accounting for the user-opened path and don't let the in-process background value overwrite the displayed one — or, if the change is deliberate, call it out in the README/CHANGELOG so it's not a silent metric change? Happy to talk through the tradeoff if avoiding a subprocess in the menu-bar path is the constraint.

---

I’ll convert this PR into a draft after submitting this review. Please press Ready for review when it’s ready and we’ll have a look 😊

[Olli0103]

@pernielsentikaer Thanks for catching the metric regression. The latest update restores getMemoryUsage() for the user-opened menu, so it uses the same app + wired + compressed accounting as the Memory tab. The 10-second background refresh now keeps the last user-collected Memory value, or shows no value before the first opening. It does not run the memory collector.

I invalidated the earlier cache format and updated the README and changelog to explain this behavior. Local validation passes with 70 tests, lint, build, and typecheck. The 60-second soak recorded zero background memory, network, or temperature collector calls. CI and Greptile are rerunning on the new commit.

[pernielsentikaer]

Looks good to me, approved 🔥

[github-actions]

Published to the Raycast Store:
https://raycast.com/hossammourad/raycast-system-monitor

[raycastbot]

🎉 🎉 🎉

We've rewarded your Raycast account with some credits. You will soon be able to exchange them for some swag.

[greptile-apps]

This entry must keep {PR_MERGE_DATE} instead of a fixed date. The merge flow replaces that placeholder with the real merge date. Restore the placeholder to follow the changelog rule.

Suggested change

	## [Menu Bar Process Safety] - 2026-09-21
	## [Menu Bar Process Safety] - {PR_MERGE_DATE}

Rule Used: What: Changelog entries must use {PR_MERGE_DATE} placeholder in titles, be placed at the top of the file, and maintain descending version order. Why: Standardized placeholders and consistent ordering ensure changelogs are maintainable and merge da... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: extensions/system-monitor/CHANGELOG.md
Line: 3

Comment:
This entry must keep `{PR_MERGE_DATE}` instead of a fixed date. The merge flow replaces that placeholder with the real merge date. Restore the placeholder to follow the changelog rule.

```suggestion
## [Menu Bar Process Safety] - {PR_MERGE_DATE}
```

**Rule Used:** What: Changelog entries must use `{PR_MERGE_DATE}` placeholder in titles, be placed at the top of the file, and maintain descending version order.  Why: Standardized placeholders and consistent ordering ensure changelogs are maintainable and merge da... ([source](https://app.greptile.com/raycast/-/custom-context?memory=c2214c11-df56-490a-b1c0-09a385df481a))

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!