[Bug] v0.0.70 - App crashes on workspace hover when multiple workspaces/chats are open

[Wallet0013]

Environment

• Version: 0.0.70
• OS: macOS Sequoia 15.7.4 (24G517)
• Architecture: ARM-64 (Apple Silicon)
• Trigger condition: Multiple workspaces + multiple chats open simultaneously; likely correlates with number of concurrently running Claude Code instances

Summary

When multiple workspaces and chats are open, hovering over the workspace list causes the app to crash, leaving the screen completely blank.

Steps to Reproduce

1. Open multiple workspaces
2. Open multiple chats within those workspaces
3. (Optional: run multiple Claude Code instances concurrently)
4. Hover the mouse over the workspace list

→ App crashes, screen goes blank

Expected Behavior

Hovering over the workspace list displays workspace info/preview without issues.

Actual Behavior

The app crashes immediately on hover and the screen becomes entirely unresponsive/blank.

Crash Analysis

• Exception: EXC_BREAKPOINT (SIGTRAP) — triggered by a failed assertion in V8
• Crashed thread: CrRendererMain (main thread)
• Root cause indicator: v8::api_internal::FromJustIsNothing() is called repeatedly in the stack trace. This fires when a Maybe<> value is unwrapped via .FromJust() while it is actually Nothing — i.e., a null/undefined value is being accessed without a null-check in the renderer process
• Concurrent GC pressure: Multiple ThreadPoolForegroundWorker threads are simultaneously executing cppgc::internal::ExplicitManagementImpl::Resize, indicating heavy garbage collection activity at the time of crash. This suggests a potential race condition between the hover-triggered rendering logic and GC
• Two separate crash reports collected on 2026-02-21 and 2026-02-22 show identical exception type and crash thread, confirming reproducibility

Crash Logs

Crash Report #1 — 2026-02-22 07:52:34

Process:               1Code Helper (Renderer) [1520]
Path:                  /Applications/1Code.app/Contents/Frameworks/1Code Helper (Renderer).app/Contents/MacOS/1Code Helper (Renderer)
Identifier:            dev.21st.agents.helper.Renderer
Version:               0.0.70
Code Type:             ARM-64 (Native)
Parent Process:        1Code [1508]
User ID:               [REDACTED-UID]

Date/Time:             2026-02-22 07:52:34.1423 +0900
OS Version:            macOS 15.7.4 (24G517)
Report Version:        12
Anonymous UUID:        [REDACTED-UUID]

Time Awake Since Boot: 860 seconds
System Integrity Protection: enabled

Crashed Thread:        0  CrRendererMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x0000000112139968
Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [1520]

Thread 0 Crashed:: CrRendererMain Dispatch queue: com.apple.main-thread
0   Electron Framework               0x112139968 ares_dns_rr_get_ttl + 3664896
1   Electron Framework               0x112139968 ares_dns_rr_get_ttl + 3664896
2   Electron Framework               0x112139980 ares_dns_rr_get_ttl + 3664920
3   Electron Framework               0x11213999c ares_dns_rr_get_ttl + 3664948
4   Electron Framework               0x10f6f1b44 node::sqlite::UserDefinedFunction::xDestroy(void*) + 30000
5   Electron Framework               0x1104bb14c v8::PropertyDescriptor::set() const + 4479060
6   Electron Framework               0x1104bb0e0 v8::PropertyDescriptor::set() const + 4478952
...
11  Electron Framework               0x10e1600ec v8::api_internal::FromJustIsNothing() + 1212
12  Electron Framework               0x10e160924 v8::api_internal::FromJustIsNothing() + 3316
[FromJustIsNothing repeats through frame 29]
...
31  Electron Framework               0x10db645d8 v8::ValueDeserializer::ReadValue(v8::Local<v8::Context>) + 564
...
55  Electron Framework               0x10f566480 ElectronMain + 124
56  1Code Helper (Renderer)          0x102918e24 0x102910000 + 36388

Thread 0 crashed with ARM Thread State (64-bit):
   esr: 0xf2000000 (Breakpoint) brk 0

Binary Images:
   Electron Framework: com.github.Electron.framework, version 39.4.0
   UUID: 4c4c444b-5555-3144-a1c9-6f5f40520684

Crash Report #2 — 2026-02-21 21:25:45

Process:               1Code Helper (Renderer) [53951]
Path:                  /Applications/1Code.app/Contents/Frameworks/1Code Helper (Renderer).app/Contents/MacOS/1Code Helper (Renderer)
Identifier:            dev.21st.agents.helper.Renderer
Version:               0.0.70
Code Type:             ARM-64 (Native)
Parent Process:        1Code [7452]
User ID:               [REDACTED-UID]

Date/Time:             2026-02-21 21:25:45.4944 +0900
OS Version:            macOS 15.7.4 (24G517)
Anonymous UUID:        [REDACTED-UUID]
Sleep/Wake UUID:       [REDACTED-UUID]

Time Awake Since Boot: 69000 seconds
System Integrity Protection: enabled

Crashed Thread:        0  CrRendererMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x000000010d9872a8
Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5

Thread 0 Crashed:: CrRendererMain Dispatch queue: com.apple.main-thread
0   Electron Framework               0x10d9872a8 node::PrincipalRealm::maybe_cache_generated_source_map() const + 209640
1   Electron Framework               0x10d9a1a50 node::sqlite::UserDefinedFunction::xDestroy(void*) + 29756
2   Electron Framework               0x10e76b14c v8::PropertyDescriptor::set() const + 4479060
...
[Multiple ??? frames indicating JIT-compiled JavaScript execution at time of crash]
...
42  Electron Framework               0x10b575710 v8::Function::Call(...) + 6720
...
56  Electron Framework               0x10d816480 ElectronMain + 124
57  1Code Helper (Renderer)          0x1008dce24 0x1008d4000 + 36388

Thread 8 (ThreadPoolForegroundWorker) — also active:
   v8::internal::OptimizingCompileTaskExecutor running concurrently
   → JIT compiler under high load at time of crash

Thread 0 crashed with ARM Thread State (64-bit):
   esr: 0xf2000000 (Breakpoint) brk 0

Binary Images:
   Electron Framework: com.github.Electron.framework, version 39.4.0
   UUID: 4c4c444b-5555-3144-a1c9-6f5f40520684

[1code-async]

Task completed.

The enrichment comment has been posted on issue #170. Here's a summary of the analysis:

Root Cause: The crash is a V8-level deserialization failure (FromJustIsNothing) in Electron's IPC layer. When multiple Claude Code sessions are actively streaming data through tRPC subscriptions, the renderer process is under heavy GC pressure. Hovering over the workspace list triggers additional IPC prefetch calls (agents-sidebar.tsx:2839-2878) that push the V8 deserializer past its limits, causing it to hit an internal assertion on a Nothing value.

Key contributing factors identified:

• Unbounded concurrent tRPC streaming subscriptions from multiple active Claude sessions
• An event listener leak in ipc-chat-transport.ts:489 (abort listeners never removed)
• Unbounded in-memory caches in the Claude router (main process)
• Module-level Chat object storage outside React lifecycle

Prioritized fix suggestions range from immediate mitigations (debounce prefetch during active streaming, add error boundaries) to structural improvements (cap concurrent streams, fix listener leaks, bound caches).

---

View full conversation

Powered by 1Code

[1code-async]

Task completed.

Posted the enrichment comment on issue #170: #170 (comment)

Summary of findings:

• The crash is a V8 FromJustIsNothing() assertion failure in the renderer process during structured clone deserialization
• The hover handler at agents-sidebar.tsx:2839 fires prefetch IPC calls for each workspace item hovered, which adds serialization load
• With multiple concurrent Claude sessions streaming messages via tRPC subscriptions, the IPC serialization pipeline is already under heavy load
• The crash sequence is: high IPC traffic from concurrent sessions → GC pressure → hover prefetch adds more IPC requests → V8 structured clone fails during deserialization when GC has moved/collected objects → EXC_BREAKPOINT kills the renderer → blank screen
• Related closed issues [LOW] Memory leak risk in session management #111 (memory leak in session management) and Claude process crashes on second message (session resume failure) #69 (session resume crash) may share contributing factors
• Key mitigation suggestions: debounce hover prefetch, snapshot message arrays before serialization, handle render-process-gone for crash recovery, and investigate the Electron version for known V8 bugs

---

View full conversation

Powered by 1Code

[1code-async]

Codebase Analysis

Hover Trigger Path

When hovering over workspace items, the handler at src/renderer/features/sidebar/agents-sidebar.tsx:2839-2878 (handleAgentMouseEnter) executes:

1. Searches the full agentChats array via .find() to locate the hovered chat (line 2845)
2. Fires a prefetch — either prefetchRemoteChat (network fetch via remoteApi.getAgentChat) or prefetchLocalChat (tRPC chats.get.prefetch) — lines 2846-2851
3. Checks DOM truncation on the name element and sets a 1-second tooltip timer (lines 2858-2875)

The hover handler itself is lightweight (DOM manipulation, no React state updates). The crash is unlikely caused by the tooltip logic alone. The more probable chain is: hover → prefetch → IPC serialization under memory pressure → V8 crash.

Likely Root Cause: IPC Serialization Under GC Pressure

The crash stack shows v8::ValueDeserializer::ReadValue → repeated v8::api_internal::FromJustIsNothing() calls. This indicates V8's structured clone algorithm encountered a Nothing (null) value during object deserialization — typically when serializing/deserializing objects across the IPC boundary while V8's garbage collector is actively reclaiming memory.

With multiple workspaces and concurrent Claude Code sessions, several factors compound:

1. Heavy IPC message traffic — Each active Claude session streams messages via tRPC subscription (src/main/lib/trpc/routers/claude.ts:806-843). Multiple concurrent sessions multiply the serialization load across the IPC bridge.

2. Large message arrays serialized without snapshots — Messages are accumulated and serialized with JSON.stringify() at claude.ts:915, claude.ts:958, and similar locations. These can be large arrays with deep object graphs. No defensive copy is made before serialization.

3. Concurrent session map mutation — The activeSessions Map and agentChatStore (src/renderer/features/agents/stores/agent-chat-store.ts:8-58) are module-level Maps mutated from multiple call sites without synchronization. The clear() method at line 49-57 iterates chats.values() while other code paths may be deleting entries.

4. Prefetch on hover adds to serialization queue — Each hover fires prefetchLocalChat → utils.chats.get.prefetch() (src/renderer/lib/hooks/use-prefetch-local-chat.ts:9) or prefetchRemoteChat → queryClient.prefetchQuery() (src/renderer/lib/hooks/use-remote-chats.ts:91-104). When rapidly hovering over the workspace list, this queues many concurrent IPC requests, pushing the already-stressed serialization pipeline over the edge.

Crash Sequence (Hypothesis)

1. Multiple Claude sessions are streaming → high IPC message volume → V8 heap pressure
2. GC threads are actively running (ThreadPoolForegroundWorker + cppgc::internal::ExplicitManagementImpl::Resize visible in crash logs)
3. User hovers over workspace list → rapid prefetch calls fire
4. A prefetch response arrives and V8 attempts to deserialize the IPC payload via structured clone
5. During deserialization, GC has moved/collected part of the object graph → FromJustIsNothing() assertion fires
6. EXC_BREAKPOINT (SIGTRAP) kills the renderer process → blank screen

Related Issues

• [LOW] Memory leak risk in session management #111 (closed) — "Memory leak risk in session management" — directly relevant; if session cleanup is incomplete, it compounds the memory pressure that triggers this crash
• Claude process crashes on second message (session resume failure) #69 (closed) — "Claude process crashes on second message (session resume failure)" — different trigger, similar crash pattern in the renderer process

Relevant Files

File	Relevance
src/renderer/features/sidebar/agents-sidebar.tsx:2839-2878	Hover handler that triggers prefetch
src/renderer/lib/hooks/use-prefetch-local-chat.ts	Local chat prefetch (tRPC IPC call)
src/renderer/lib/hooks/use-remote-chats.ts:91-104	Remote chat prefetch (network call)
src/main/lib/trpc/routers/claude.ts:806-960	Subscription setup, session tracking, message serialization
src/renderer/features/agents/stores/agent-chat-store.ts	Module-level Map storing active Chat objects
src/renderer/features/agents/lib/ipc-chat-transport.ts:188-209	State query at stream start, subscription setup

Suggested Investigation Approaches

1. Throttle/debounce hover prefetch — The handleAgentMouseEnter handler fires a prefetch for every workspace item hovered. Adding a debounce (e.g., 150ms) or limiting concurrent prefetches would reduce IPC pressure during rapid mouse movement over the list.

2. Snapshot message arrays before serialization — In claude.ts, deep-clone messagesToSave before passing to JSON.stringify() to prevent the serializer from traversing an object graph that may be mutated concurrently.

3. Investigate Electron version — The crash is in Electron Framework 39.4.5 (com.github.Electron.framework, version 39.4.0). There are known V8 structured clone bugs in certain Chromium versions under GC pressure. Check if a newer Electron patch addresses this.

4. Add renderer crash recovery — Since the crash kills CrRendererMain, implementing Electron's render-process-gone event handler in the main process could detect the crash and reload the renderer instead of showing a blank screen.

5. Profile memory with multiple sessions — Use --js-flags="--expose-gc" and Chrome DevTools to monitor heap growth when multiple sessions are active, to identify whether there's a memory leak that lowers the threshold for this crash.

[1code-async]

Codebase Analysis

Relevant Code Paths

The crash occurs in the renderer process when hovering over workspace cards in the sidebar. Here's the code flow:

1. Hover Entry Point — handleAgentMouseEnter in src/renderer/features/sidebar/agents-sidebar.tsx:2839-2878

When the mouse enters a workspace card, this handler:

• Calls prefetchLocalChat(chatId) or prefetchRemoteChat(chatId) to pre-warm the React Query cache
• Checks if the workspace name is truncated (scrollWidth > clientWidth)
• Starts a 1-second timer to show a custom DOM-based tooltip

2. Chat Prefetch on Hover — src/renderer/lib/hooks/use-prefetch-local-chat.ts:8-9 and src/renderer/lib/hooks/use-remote-chats.ts:91-104

Each hover fires a tRPC prefetch (utils.chats.get.prefetch) or a direct API call (remoteApi.getAgentChat). With many workspaces open, rapidly hovering across the list triggers many concurrent IPC round-trips through the trpc-electron bridge.

3. Polling Queries Adding Pressure — agents-sidebar.tsx:1923-1932

Two tRPC queries run on 5-second polling intervals for all open sub-chats:

• trpc.chats.getFileStats.useQuery(...) with refetchInterval: 5000
• trpc.chats.getPendingPlanApprovals.useQuery(...) with refetchInterval: 5000

With many workspaces/chats open, allOpenSubChatIds grows large, causing these polling queries to serialize and deserialize increasingly large payloads every 5 seconds.

4. GitHubAvatar Image Loading — agents-sidebar.tsx:146-178

Each workspace card with a GitHub-linked project renders a GitHubAvatar component that loads https://github.com/{gitOwner}.png?size=64. When prefetch data returns and causes re-renders, these image components may remount, triggering new network requests and onLoad/onError callbacks.

Crash Mechanism

The crash signature — v8::api_internal::FromJustIsNothing() repeating in the stack, with v8::ValueDeserializer::ReadValue further down — points to V8 structured clone deserialization failing during IPC message passing. The FromJustIsNothing call fires when V8 unwraps a Maybe<> value (via .FromJust()) that is Nothing, meaning a deserialization step expected a value but found none.

The concurrent ThreadPoolForegroundWorker threads running cppgc::internal::ExplicitManagementImpl::Resize confirm heavy GC pressure at crash time. The likely sequence:

1. Multiple workspaces open → many active tRPC subscriptions/queries, each keeping serialized data in IPC buffers
2. Two 5-second polling queries with large payloads add constant serialization/deserialization load
3. Hover triggers additional prefetch IPC calls
4. V8's structured clone deserializer encounters a GC-relocated or collected buffer during deserialization → FromJustIsNothing assertion → SIGTRAP

This is consistent with Electron's known behavior where high-frequency IPC under memory pressure can trigger V8 assertion failures in the renderer process.

Potentially Related Closed Issues

• [LOW] Memory leak risk in session management #111 — Memory leak risk in session management (closed) — may share a root cause around session/data lifecycle
• Claude process crashes on second message (session resume failure) #69 — Claude process crashes on second message / session resume failure (closed) — similar renderer crash pattern

Suggested Investigation & Fixes

1. Debounce hover prefetch: The handleAgentMouseEnter at line 2839 fires prefetch immediately on every hover. Adding a small debounce (100-200ms) or cancelling pending prefetches on mouse leave would reduce IPC storms when scrubbing across the list.

2. Reduce polling payload size: The getFileStats and getPendingPlanApprovals queries (lines 1923-1932) send all open sub-chat IDs every 5 seconds. Consider:

   • Increasing the poll interval when many chats are open
   • Paginating or batching the response
   • Using delta-based updates instead of full refetch

3. Throttle concurrent IPC calls: Consider a concurrency limit on tRPC prefetch calls to avoid flooding the IPC bridge. React Query's queryClient.setDefaultOptions can limit concurrent queries.

4. Add error boundary around sidebar: Wrap AgentsSidebar (or at least ChatListSection) in a React error boundary so a deserialization crash doesn't blank the entire app.

5. Reproduce with DevTools: Run in dev mode, open Chrome DevTools Performance tab, and hover rapidly across workspaces to observe IPC message frequency and memory/GC timeline. The --js-flags="--expose-gc" flag can help force GC to narrow down timing.

Key Files

File	Relevance
src/renderer/features/sidebar/agents-sidebar.tsx	Main sidebar with hover handlers, polling queries, tooltip logic (3538 lines)
src/renderer/lib/hooks/use-prefetch-local-chat.ts	tRPC prefetch triggered on hover
src/renderer/lib/hooks/use-remote-chats.ts	Remote chat prefetch triggered on hover
src/main/lib/trpc/routers/chats.ts	Backend chat queries (getFileStats, getPendingPlanApprovals)
src/main/lib/trpc/routers/projects.ts	Project list query used in sidebar

[1code-async]

Issue Analysis

Crash Root Cause

The crash traces show v8::api_internal::FromJustIsNothing() called repeatedly within V8's ValueDeserializer::ReadValue path. This indicates the renderer process is crashing during IPC deserialization — V8 is trying to deserialize a value passed from the main process and encounters a Nothing (null/empty) Maybe<> that gets unwrapped with .FromJust() instead of .FromMaybe().

This is not a bug in the app's JavaScript code directly — it's a crash in the Electron/V8 layer triggered by memory pressure and GC contention in the renderer process when many concurrent Claude Code sessions are streaming data through tRPC subscriptions over IPC.

Why Hover Triggers It

The hover handler in src/renderer/features/sidebar/agents-sidebar.tsx:2839-2878 does several things that increase IPC/rendering load at the moment of hover:

1. Prefetches chat data via tRPC (prefetchLocalChat or prefetchRemoteChat) — this triggers an IPC round-trip to the main process (src/renderer/lib/hooks/use-prefetch-local-chat.ts:9)
2. Iterates agentChats array with .find() to determine if the chat is remote (line 2845)
3. Accesses DOM refs for tooltip truncation checks (nameRefs.current.get(chatId), line 2858)

When the renderer is already under heavy GC pressure from multiple active Claude streaming sessions (visible in crash report as multiple ThreadPoolForegroundWorker threads running cppgc::internal::ExplicitManagementImpl::Resize), the additional IPC deserialization from the prefetch call can hit a V8 internal assertion where a deserialized value is Nothing.

Contributing Factors Identified in Codebase

1. Unbounded IPC streaming from concurrent sessions

• Each active sub-chat creates a tRPC observable subscription (src/main/lib/trpc/routers/claude.ts:806-807) that continuously emits UIMessageChunk objects
• Multiple concurrent sessions = multiple streams of serialized data flowing through Electron's IPC, all requiring V8 deserialization in the renderer
• The trpc-electron bridge (v0.1.2) serializes all data through Electron's IPC which uses V8's structured clone algorithm

2. Event listener leak in IPC transport

• src/renderer/features/agents/lib/ipc-chat-transport.ts:489 — abort signal listeners are added with addEventListener("abort", ...) but never removed (no { once: true } or removeEventListener)
• Over many sub-chat create/destroy cycles, orphaned listeners accumulate

3. Unbounded in-memory caches in main process

• workingMcpServers Map (src/main/lib/trpc/routers/claude.ts:268) and symlinksCreated Set (line 277) grow indefinitely
• pendingToolApprovals Map (line 324) may not be cleared if sessions end abnormally

4. Module-level Chat object storage

• src/renderer/features/agents/stores/agent-chat-store.ts:8 — Chat objects stored in a module-level Map outside React lifecycle
• Cleanup relies on explicit delete() calls which may not happen for all edge cases

Related Closed Issues

• [LOW] Memory leak risk in session management #111 — Memory leak risk in session management (closed) — directly related; the session cleanup gaps identified there may still be contributing
• Claude process crashes on second message (session resume failure) #69 — Claude process crashes on second message (session resume failure) — similar crash pattern involving session management
• [MEDIUM] Large database queries without pagination #109 — Large database queries without pagination — could compound memory pressure

Suggested Fixes (Prioritized)

P0 — Immediate mitigation:

1. Debounce/skip prefetch during active streaming — In handleAgentMouseEnter, skip prefetchLocalChat/prefetchRemoteChat calls when there are active Claude streaming sessions. This avoids adding IPC load during peak GC pressure.
2. Add error boundary around sidebar — Wrap the sidebar component tree in a React error boundary so a crash in hover/prefetch doesn't blank the entire app.

P1 — Address memory pressure:
3. Fix abort listener leak — Add { once: true } to the addEventListener("abort", ...) call in ipc-chat-transport.ts:489.
4. Bound the workingMcpServers and symlinksCreated caches — Add LRU eviction or periodic cleanup.
5. Add timeout to pendingToolApprovals — Auto-reject after a timeout to prevent indefinite retention.

P2 — Structural improvements:
6. Limit concurrent Claude streaming sessions — Cap the number of simultaneously active tRPC subscriptions (e.g., pause/buffer streams for non-visible sub-chats).
7. Investigate trpc-electron serialization — The V8 ValueDeserializer crash path suggests the structured clone of UIMessageChunk objects may involve complex/circular references under memory pressure. Consider simplifying the chunk shape or using JSON serialization as a fallback.

Not a Duplicate

This is a unique issue — no existing open or closed issues describe this specific crash pattern (V8 deserialization failure during workspace hover under concurrent session load).