What happened?

The installed PawWork app shows sustained high CPU and memory usage on macOS. Process snapshot taken from the installed /Applications/PawWork.app (no worktree dev process running): PawWork main process PID 11983 used about 53.8% CPU and 384 MB RSS, PawWork Helper (Renderer) PID 12005 used about 49.2% CPU and 641 MB RSS, and the GPU helper used about 6.4% CPU and 115 MB RSS.

It is not yet known whether bun run dev:desktop reproduces the same process-tree behavior under the same usage pattern; that comparison has not been run. The installed-app snapshot above only confirms the resource usage, not that the root cause is production-only.

Steps to reproduce

1. Open the installed PawWork app from /Applications/PawWork.app.
2. Use a normal session flow for a while.
3. Check Activity Monitor or run ps -axo pid,ppid,%cpu,%mem,rss,command | rg "/Applications/PawWork.app|PawWork Helper".
4. Observe the main process and renderer continuing to use high CPU and hundreds of MB of memory.

What did you expect to happen?

When the app is idle or after a normal prompt-send flow finishes, CPU usage should drop back near idle. Renderer and main-process memory should remain bounded enough that the app does not cause heat, fan, or battery drain during normal use.

PawWork version

v0.2.13

OS version

macOS 26.3.1 (a), build 25D771280a

Can you reproduce it again?

Sometimes

Screenshots, recordings, or extra context

This needs a focused performance pass. Diagnostic plan, in order:

1. Reproduce in bun run dev:desktop with the same session flow and inspect the process tree (ps -axo + Chrome DevTools renderer profiler). Most likely root causes (uncleared setInterval / requestAnimationFrame, leaking createResource subscriptions, reactive graph blowup, IPC handler leaks, unreleased streams) reproduce in dev.
2. If dev does not reproduce, then narrow to production-only paths: updater main loop, code-signing + sandbox-only branches, native module bundling differences, Helper process behavior. These need an installed dmg to capture (spindump, sample, Activity Monitor process tree).
3. If dev does reproduce, fix in dev first; the installed-app symptom should resolve once the underlying loop / leak is fixed.

Suggested signals to capture once a repro is reliable: which polling, animation, resource refetch, sidecar stream, or markdown/render loop remains active while the app is visually idle. Current priority is P1 because the issue affects the installed desktop app core experience and can cause battery/heat problems, but it is not P0 because the app remains usable and no data loss or complete workflow block has been confirmed.