## Issue Description
After a long-running session (the renderer process had been alive ~2 days), the `Qoder Helper (Renderer)` process saturates the CPU — observed up to **194%** in macOS Activity Monitor, with fans spinning up.
A CPU sample (`/usr/bin/sample`, 8s) shows the renderer **main thread spending ~86% of its time building JavaScript Error stack traces**, not in normal layout/paint:
```
6925 com.apple.main-thread
└─ ElectronMain → V8 → v8::Function::Call
└─ v8::StackTrace::CurrentStackTrace (entire hot path)
└─ 5966 v8::StackFrame::GetSourcePosition() const ← 86% of main-thread samples
```
- `v8::StackFrame::GetSourcePosition()` = **5966 / 6925 ≈ 86%** of main-thread time
- `v8::StackTrace::CurrentStackTrace()` present throughout, deep recursion
- Negligible time in layout / paint / GPU — this is **not** a rendering-cost issue
`GetSourcePosition` is invoked when V8 materializes an Error’s `.stack` (mapping each frame’s bytecode offset → source line/column). 86% of CPU here means the renderer is generating Error stack traces in a tight loop — likely a webview / extension error path, with state accumulating over the session.
Process facts at sample time: PID alive ~2 days, Physical footprint 1.7 GB (peak 1.9 GB).
**Suspected root cause:** a hot loop that repeatedly creates `Error` + reads `.stack` (or `Error.captureStackTrace` / `console.trace`, or a telemetry/error-reporting path that captures stacks per event), triggered by long-lived webview/conversation state.
## Steps to Reproduce
1. Open Qoder on macOS (Apple Silicon) and keep it running for a long time (sessions spanning ~1-2 days, multiple workspace windows, AI assistant active).
2. Continue normal AI-assisted coding work over the session.
3. Open Activity Monitor and watch `Qoder Helper (Renderer)`.
4. CPU climbs and stays high (observed up to ~194%); it does not drop back when idle.
Note: this is a sustained spike, not a brief render burst, and the same renderer process accumulates over days.
## Expected Behavior
The renderer should not spend the majority of CPU generating Error stack traces. Idle/steady-state CPU should return to near zero, and long sessions should not accumulate into a persistent high-CPU state.
## Actual Behavior
Renderer main thread is pinned at ~86% in `v8::StackFrame::GetSourcePosition` / `v8::StackTrace::CurrentStackTrace`, driving overall process CPU up to ~194% and keeping it there until the window is reloaded.
**Workaround that confirms the cause:** running `Reload Window` (Command Palette) rebuilds the renderer and drops CPU back to normal — confirming it is accumulated renderer/webview state, not external load. Restarting Qoder also clears it.
**Suggested fixes:** identify and rate-limit/remove the hot Error-stack path; avoid reading `.stack` in steady-state loops; cache or skip source-position resolution for repeated identical stacks; throttle/dedupe telemetry stack capture per session; periodically clean up webview state for long sessions.
## Screenshots / Screen Recordings
- Activity Monitor showing `Qoder Helper (Renderer)` at 194% CPU. [attach screenshot]
- Full 8-second CPU sample (`qoder_renderer.txt`, ~2.4 MB) — key hot frames quoted above. [attach file]
## Operating System
macOS 15.7.4 (build 24G517), Apple Silicon — Apple M2, 16 GB RAM (ARM64)
## Current Qoder Version (Menu → About Qoder → Copy)
```
Qoder Version: 1.10.1
Commit: 4b7e1dfe9572232d5d5b201fa7b778877f908e5f
Date: 2026-06-23T12:58:35.452Z
VS Code core: 1.106.3
Electron: 37.7.0
OS: Darwin arm64 24.6.0 (macOS 15.7.4, build 24G517)
```