macOS: setStableProcessTitle() runs every 5 s → one LaunchServices check-in per session every 5 s (launchservicesd CPU)
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 74/100
- Issue-Typ
- Bug
- Klarheit
- Klar beschrieben
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- javascript, macos, node.js
- Bereich
- cli, performance
Rechercherichtung
Lies den im Issue gezeigten Code für writeTitle() und setStableProcessTitle() und verfolge dann, wo useTerminalTitle reassertTerminalTitle() einplant. Prüfe die minimale Node-Reproduktion unter macOS, um zu bestätigen, dass wiederholte Zuweisungen Check-ins auslösen. Fertig ist die Änderung, wenn der Terminaltitel weiterhin alle 5 Sekunden erneut gesetzt werden kann, ohne wiederholte Prozess-Titelzuweisungen vorzunehmen, und die Reproduktion keine wiederkehrenden Check-ins zeigt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Summary
Since the fix for #764 (v1.50.1), the process title is stable (command-code) — thanks.
But writeTitle() calls setStableProcessTitle() on every call, and
useTerminalTitle re-asserts the terminal title every 5 s:
function setStableProcessTitle(){process.title="command-code"}
function writeTitle(e){setStableProcessTitle(),process.stderr.isTTY&&process.stderr.write(SN(e))}
function reassertTerminalTitle(){null!==wN&&writeTitle(wN)}
// useTerminalTitle:
const e=setInterval(reassertTerminalTitle,5e3)
On macOS, every process.title assignment goes through libuv's darwin
proctitle code, which checks the process in with LaunchServices. lsd logs
pid N registering self and the check-in is rejected with -10811
(kLSNotAnApplicationErr), but launchservicesd still does the work (code
signature validation) each time. So every interactive session costs one
LaunchServices check-in every 5 s, forever, idle or not, even though the
value never changes.
Impact (measured)
macOS 26.6 (25G72), Apple Silicon (M5 Max, 18 cores), Node v24.21.0 arm64,
Command Code 1.79.1, ~20–30 interactive sessions open in a terminal multiplexer:
- 12 check-ins / min per session, constant (10-min idle window: 119–120 per session).
- 45-min audit:
launchservicesdwas the #1 CPU consumer of the machine:
353 % average, 433 % p95 (≈3.5 cores); 84 of 87registering self
events per probe window came from Command Code processes. - Controlled experiment with throw-away sessions (
--no-session, no prompt sent):
baseline 257 % → +4 sessions 316 % → +8 sessions 362 %launchservicesdCPU
(≈12–15 % of a core per session, ≈0.7 s oflaunchservicesdCPU per check-in).
Those throw-away sessions ran Node x86_64 under Rosetta; arm64 sessions show
the same 12 / min cadence.
Minimal repro (no Command Code needed)
node -e 'setInterval(()=>{process.title="command-code"},5000)' & A=$! # rewrite every 5 s
node -e 'process.title="command-code"; setInterval(()=>{},5000)' & B=$! # write once
sleep 42
log show --last 40s --style compact \
--predicate 'process == "lsd" AND eventMessage CONTAINS "registering self"' > lsd.txt
grep -c "pid $A registering self" lsd.txt # → 8
grep -c "pid $B registering self" lsd.txt # → 0
kill $A $B
With Command Code itself: start one session in a terminal, then
log stream --predicate 'process == "lsd" AND eventMessage CONTAINS "registering self"'
shows its pid every 5.000 s.
Suggested fix
Only write the process title when it changes, e.g.
function setStableProcessTitle(){ if (process.title !== "command-code") process.title = "command-code" }
or call it once at startup instead of inside writeTitle(). The OSC terminal
title write can stay on the 5 s interval — it does not touch LaunchServices.
Local workaround (until a release)
A user mod in ~/.commandcode/mods/ that performs the native write once and
then backs process.title with a plain JS property removes the check-ins
(same loop: 8 → 0 per 40 s; ps still shows command-code). It only takes
effect after a session's first message (mods load with the harness).
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 4.1k
- Forks
- 363
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus CommandCodeAI/command-code
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 85/100
CommandCodeAI/command-code#992 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#933 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#855 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
CommandCodeAI/command-code#841 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#655 · 1 Kommentar ·
Alle Issues in CommandCodeAI/command-code
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
Sendspin/sendspin-python-cli#291 ·
Maintainer antworten meist innerhalb von 6 Tagen
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
components-web-app/docs#193 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
rescript-lang/rescript#8761 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
ccch1mneyyy/dsh-TUI#1452 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100