Native V8 array-length crash during active tool-heavy turns and session resume

Describe the bug

The packaged Linux x64 native binary aborts inside V8 during active, tool-heavy turns as well as while resuming conversations.

The original report attributed this to several concurrent resumes. Further testing disproved that: Herdr automatic restoration was disabled, failed panes were cleared, and an already-running conversation crashed mid-turn while displaying:

Reviewing brief clarity · 29.4 KiB
# Fatal error in , line 0
# Fatal JavaScript invalid array length 0

A second active conversation failed similarly while displaying Shipping Lakebase refactor · 53.7 KiB. Both ended with SIGILL. These were normal active turns, not startup or bulk restore.

The fatal string maps to V8's Accessors::ArrayLengthSetter, where JSArray::SetLength(..., 0) returned an exception and V8 called FATAL:

https://github.com/v8/v8/blob/main/src/builtins/accessors.cc#L210-L214

Affected version

GitHub Copilot CLI 1.0.70

Steps to reproduce the behavior

A minimal deterministic reproduction is not yet available. The recurring observed sequence is:

1. Start or resume a Copilot conversation.
2. Run a long, tool-heavy workflow with many subagents.
3. Start another turn.
4. While Copilot is actively streaming/reviewing the response, the native process aborts with Fatal JavaScript invalid array length 0 and SIGILL.

Two affected conversation histories were approximately:

• 14.1 MB / 2,482 events / 929 completed tool calls / 23 completed subagents
• 21.3 MB / 3,959 events / approximately 1,500 completed tool calls / 24 started subagents

The final persisted event in each is assistant.turn_start without a matching assistant.turn_end, confirming the failure occurred mid-turn.

Expected behavior

Long or tool-heavy conversations should continue normally. If an internal array operation fails, the CLI should surface a recoverable JavaScript error rather than aborting the native process.

Additional context

• OS: Ubuntu 24.04 under WSL2, Linux 6.6.114.1-microsoft-standard-WSL2, x86_64
• Terminal: Windows Terminal -> Herdr PTYs
• Shell: zsh
• Memory after the latest crash: 31 GiB total, 28 GiB available, no swap in use
• Copilot's embedded runtime reports Node.js v24.16.0
• Kernel logs show repeated SIGILL failures at the same native address
• app.js and index.js checksums match between the npm platform package and Copilot's update cache
• The npm loader's subsequent no platform package found message is misleading; the platform package launched successfully and its child process terminated by signal
• Reinstalling npm replaces 1.0.70 with the same 1.0.70 and does not resolve the failure
• Herdr's resume_agents_on_restore setting is not required to trigger this
• Running the packaged JavaScript entrypoint under system Node.js v24.11.1 passes startup/version and interactive Herdr smoke tests. I am testing this as a temporary workaround, but it has not yet had the same long-duration workload.

パッケージ化された JavaScript エントリポイント app.js と index.js から始め、文書化されたシステム Node.js workaround の下での動作を比較します。可能であれば、長く多数のツールを使用するアクティブターンの workflow を再現し、ネイティブの失敗を記録します。作業完了の条件は、ワークロードが V8 invalid-array-length SIGILL で中断されなくなるか、CLI が代わりに回復可能なエラーを提示することです。