[BUG] Claude Code Crashing
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Bug report: Claude desktop app crashes on GPU process fault during browser preview (Windows, Intel Arc)</h1>
<h2>Summary</h2>
<p>The Claude desktop app terminates when a Code session creates a browser preview and renders a live page. The app log ends with a GPU process crash roughly four seconds after the preview is created. Chat and the rest of the UI are unaffected; the crash only occurs once a session begins browser/page-script work. Reproduced three times.</p>
<h2>Environment</h2>
Item | Value
-- | --
OS | Windows 11 Pro
Claude desktop app | 1.40609.0.0 (MSIX package)
Claude Code binary | 2.1.247
Model / settings | Opus 5, High effort, Bypass permissions
GPU | Intel Arc 140T (16 GB)
GPU driver | 32.0.101.8860, dated 2026-06-24
GPU device status | OK
RAM | 32 GB
Disk | NVMe 1 TB, Healthy / OK, ~785 GB free
<h2>Reproduction steps</h2>
<ol>
<li>Open the Code tab and start a session on a local project directory.</li>
<li>Give the session a task that involves verifying a live web page.</li>
<li>The session runs commands normally, then creates a browser preview and executes a page script.</li>
<li>The app terminates.</li>
</ol>
<h2>Observed behavior</h2>
<p>Final lines of <code>%LOCALAPPDATA%\Claude\Logs\main.log</code>:</p>
<pre><code>19:00:28 [info] [Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-...","name":"Browser","status":"running",...}]' }
19:00:28 [info] [Preview] Created browser preview { serverId: 'browser-preview-...' }
19:00:28 [info] using oauth config { ... }
19:00:29 [info] using oauth config { ... }
19:00:31 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
19:00:32 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}
</code></pre>
<p>The log ends there. No shutdown sequence is written.</p>
<h2>Ruled out during investigation</h2>
<ul>
<li><strong>Memory.</strong> The app's own telemetry line at 19:00:23, nine seconds before the crash, reports <code>tree_rss_sum=2029MB</code>, <code>sys_free=17871MB/32213MB</code>. Not a memory ceiling or OOM kill.</li>
<li><strong>Disk space.</strong> ~785 GB free.</li>
<li><strong>Disk health.</strong> <code>Get-PhysicalDisk</code> reports Healthy / OK.</li>
<li><strong>Antivirus.</strong> Windows Security protection history shows no recent actions and no quarantined Claude items. No third-party AV quarantine involvement found.</li>
<li><strong>GPU hardware state.</strong> <code>Get-PnpDevice -Class Display</code> reports Status OK.</li>
<li><strong>Storage Sense.</strong> Enabled but scoped to temp files, Recycle Bin, and Downloads; does not reach package directories.</li>
</ul>
<h2>Secondary issues found along the way</h2>
<p>These may or may not be related, but were observed on the same machine.</p>
<p><strong>1. Package entered <code>Modified, NeedsRemediation</code> state; Repair and Reset both failed.</strong></p>
<p>Before the reinstall, <code>Get-AppxPackage</code> reported:</p>
<pre><code>Status : Modified, NeedsRemediation
</code></pre>
<p>Settings → Installed apps → Claude → Repair returned "We couldn't repair this app. Try again in a bit." Reset returned the equivalent message. <code>Get-AppxLog</code> showed the Register operation completing with <code>result 0x0 (step 4 of 4)</code> and ACLs repaired successfully, yet the status remained <code>NeedsRemediation</code> — the repair reported success without resolving the underlying condition. An <code>error 0x80070015</code> (<code>ERROR_NOT_READY</code>) on notifying the pre-launch service also appears in the deployment log.</p>
<p>Resolved by full removal (<code>Remove-AppxPackage</code>, including <code>-AllUsers</code>) and clean reinstall. Worth noting that a repair which reports success while leaving the package in <code>NeedsRemediation</code> is itself arguably a bug, since it gives the user no signal that a reinstall is required.</p>
<p><strong>2. Cowork VM bundle never downloaded.</strong></p>
<p><code>cowork_vm_node.log</code> logs routine VM client loads going back to 2026-08-21, then from 18:26:55 onward repeats:</p>
<pre><code>[Bundle:status] rootfs.vhdx missing
[Bundle:status] vmlinuz missing
[Bundle:status] initrd missing
</code></pre>
<p>A filesystem search confirms no <code>.vhdx</code> file anywhere on the C: drive, and <code>%LOCALAPPDATA%\Claude</code> contains only a <code>Logs</code> directory — no bundle folder at all. The app repeats the "missing" status without surfacing any error to the user or apparently retrying the download. This is separate from the GPU crash (the Code tab uses its own <code>claude-code</code> binary and does not require the VM), but Cowork is presumably non-functional as a result.</p>
<p><strong>3. Documentation/log-path mismatch.</strong></p>
<p>Community documentation and several GitHub issues describe Windows MSIX installs storing data under <code>%LOCALAPPDATA%\Packages\Claude_<hash>\LocalCache\Roaming\Claude\</code>. On this install that path does not exist at all. Actual locations:</p>
<ul>
<li>Logs: <code>%LOCALAPPDATA%\Claude\Logs\</code></li>
<li>Config and Claude Code binary: <code>%APPDATA%\Claude\</code></li>
</ul>
<p>This cost significant time during troubleshooting. If the storage location changed between versions, the docs appear not to reflect it.</p>
<h2>Notes</h2>
<ul>
<li>The <code>[PreviewContext] Blocked subresource to private-resolving host</code> warning one second before the crash may be relevant or may be incidental — the project under test is served locally, so the block itself is expected behavior.</li>
<li>Exit code 101457950 (0x60C_xxxx range) was not decoded further.</li>
<li>A newer Intel Arc driver has not yet been tested; Dell's update tool reports no update available, though Intel typically ships Arc drivers ahead of OEM packages.</li>
</ul>
<h2>Workaround</h2>
<p>Sessions remain stable if the browser preview / page script step is avoided. All other Code functionality — file edits, command execution, grep, git operations — worked normally right up to the preview step.</p></body></html><!--EndFragment-->
</body>
</html>
What Should Happen?
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Bug report: Claude desktop app crashes on GPU process fault during browser preview (Windows, Intel Arc)</h1>
<h2>Summary</h2>
<p>The Claude desktop app terminates when a Code session creates a browser preview and renders a live page. The app log ends with a GPU process crash roughly four seconds after the preview is created. Chat and the rest of the UI are unaffected; the crash only occurs once a session begins browser/page-script work. Reproduced three times.</p>
<h2>Environment</h2>
Item | Value
-- | --
OS | Windows 11 Pro
Claude desktop app | 1.40609.0.0 (MSIX package)
Claude Code binary | 2.1.247
Model / settings | Opus 5, High effort, Bypass permissions
GPU | Intel Arc 140T (16 GB)
GPU driver | 32.0.101.8860, dated 2026-06-24
GPU device status | OK
RAM | 32 GB
Disk | NVMe 1 TB, Healthy / OK, ~785 GB free
<h2>Reproduction steps</h2>
<ol>
<li>Open the Code tab and start a session on a local project directory.</li>
<li>Give the session a task that involves verifying a live web page.</li>
<li>The session runs commands normally, then creates a browser preview and executes a page script.</li>
<li>The app terminates.</li>
</ol>
<h2>Observed behavior</h2>
<p>Final lines of <code>%LOCALAPPDATA%\Claude\Logs\main.log</code>:</p>
<pre><code>19:00:28 [info] [Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-...","name":"Browser","status":"running",...}]' }
19:00:28 [info] [Preview] Created browser preview { serverId: 'browser-preview-...' }
19:00:28 [info] using oauth config { ... }
19:00:29 [info] using oauth config { ... }
19:00:31 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
19:00:32 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}
</code></pre>
<p>The log ends there. No shutdown sequence is written.</p>
<h2>Ruled out during investigation</h2>
<ul>
<li><strong>Memory.</strong> The app's own telemetry line at 19:00:23, nine seconds before the crash, reports <code>tree_rss_sum=2029MB</code>, <code>sys_free=17871MB/32213MB</code>. Not a memory ceiling or OOM kill.</li>
<li><strong>Disk space.</strong> ~785 GB free.</li>
<li><strong>Disk health.</strong> <code>Get-PhysicalDisk</code> reports Healthy / OK.</li>
<li><strong>Antivirus.</strong> Windows Security protection history shows no recent actions and no quarantined Claude items. No third-party AV quarantine involvement found.</li>
<li><strong>GPU hardware state.</strong> <code>Get-PnpDevice -Class Display</code> reports Status OK.</li>
<li><strong>Storage Sense.</strong> Enabled but scoped to temp files, Recycle Bin, and Downloads; does not reach package directories.</li>
</ul>
<h2>Secondary issues found along the way</h2>
<p>These may or may not be related, but were observed on the same machine.</p>
<p><strong>1. Package entered <code>Modified, NeedsRemediation</code> state; Repair and Reset both failed.</strong></p>
<p>Before the reinstall, <code>Get-AppxPackage</code> reported:</p>
<pre><code>Status : Modified, NeedsRemediation
</code></pre>
<p>Settings → Installed apps → Claude → Repair returned "We couldn't repair this app. Try again in a bit." Reset returned the equivalent message. <code>Get-AppxLog</code> showed the Register operation completing with <code>result 0x0 (step 4 of 4)</code> and ACLs repaired successfully, yet the status remained <code>NeedsRemediation</code> — the repair reported success without resolving the underlying condition. An <code>error 0x80070015</code> (<code>ERROR_NOT_READY</code>) on notifying the pre-launch service also appears in the deployment log.</p>
<p>Resolved by full removal (<code>Remove-AppxPackage</code>, including <code>-AllUsers</code>) and clean reinstall. Worth noting that a repair which reports success while leaving the package in <code>NeedsRemediation</code> is itself arguably a bug, since it gives the user no signal that a reinstall is required.</p>
<p><strong>2. Cowork VM bundle never downloaded.</strong></p>
<p><code>cowork_vm_node.log</code> logs routine VM client loads going back to 2026-08-21, then from 18:26:55 onward repeats:</p>
<pre><code>[Bundle:status] rootfs.vhdx missing
[Bundle:status] vmlinuz missing
[Bundle:status] initrd missing
</code></pre>
<p>A filesystem search confirms no <code>.vhdx</code> file anywhere on the C: drive, and <code>%LOCALAPPDATA%\Claude</code> contains only a <code>Logs</code> directory — no bundle folder at all. The app repeats the "missing" status without surfacing any error to the user or apparently retrying the download. This is separate from the GPU crash (the Code tab uses its own <code>claude-code</code> binary and does not require the VM), but Cowork is presumably non-functional as a result.</p>
<p><strong>3. Documentation/log-path mismatch.</strong></p>
<p>Community documentation and several GitHub issues describe Windows MSIX installs storing data under <code>%LOCALAPPDATA%\Packages\Claude_<hash>\LocalCache\Roaming\Claude\</code>. On this install that path does not exist at all. Actual locations:</p>
<ul>
<li>Logs: <code>%LOCALAPPDATA%\Claude\Logs\</code></li>
<li>Config and Claude Code binary: <code>%APPDATA%\Claude\</code></li>
</ul>
<p>This cost significant time during troubleshooting. If the storage location changed between versions, the docs appear not to reflect it.</p>
<h2>Notes</h2>
<ul>
<li>The <code>[PreviewContext] Blocked subresource to private-resolving host</code> warning one second before the crash may be relevant or may be incidental — the project under test is served locally, so the block itself is expected behavior.</li>
<li>Exit code 101457950 (0x60C_xxxx range) was not decoded further.</li>
<li>A newer Intel Arc driver has not yet been tested; Dell's update tool reports no update available, though Intel typically ships Arc drivers ahead of OEM packages.</li>
</ul>
<h2>Workaround</h2>
<p>Sessions remain stable if the browser preview / page script step is avoided. All other Code functionality — file edits, command execution, grep, git operations — worked normally right up to the preview step.</p></body></html><!--EndFragment-->
</body>
</html>
Error Messages/Logs
Steps to Reproduce
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Bug report: Claude desktop app crashes on GPU process fault during browser preview (Windows, Intel Arc)</h1>
<h2>Summary</h2>
<p>The Claude desktop app terminates when a Code session creates a browser preview and renders a live page. The app log ends with a GPU process crash roughly four seconds after the preview is created. Chat and the rest of the UI are unaffected; the crash only occurs once a session begins browser/page-script work. Reproduced three times.</p>
<h2>Environment</h2>
Item | Value
-- | --
OS | Windows 11 Pro
Claude desktop app | 1.40609.0.0 (MSIX package)
Claude Code binary | 2.1.247
Model / settings | Opus 5, High effort, Bypass permissions
GPU | Intel Arc 140T (16 GB)
GPU driver | 32.0.101.8860, dated 2026-06-24
GPU device status | OK
RAM | 32 GB
Disk | NVMe 1 TB, Healthy / OK, ~785 GB free
<h2>Reproduction steps</h2>
<ol>
<li>Open the Code tab and start a session on a local project directory.</li>
<li>Give the session a task that involves verifying a live web page.</li>
<li>The session runs commands normally, then creates a browser preview and executes a page script.</li>
<li>The app terminates.</li>
</ol>
<h2>Observed behavior</h2>
<p>Final lines of <code>%LOCALAPPDATA%\Claude\Logs\main.log</code>:</p>
<pre><code>19:00:28 [info] [Launch] Updating active servers store { count: 1, servers: '[{"serverId":"browser-preview-...","name":"Browser","status":"running",...}]' }
19:00:28 [info] [Preview] Created browser preview { serverId: 'browser-preview-...' }
19:00:28 [info] using oauth config { ... }
19:00:29 [info] using oauth config { ... }
19:00:31 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
19:00:32 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}
</code></pre>
<p>The log ends there. No shutdown sequence is written.</p>
<h2>Ruled out during investigation</h2>
<ul>
<li><strong>Memory.</strong> The app's own telemetry line at 19:00:23, nine seconds before the crash, reports <code>tree_rss_sum=2029MB</code>, <code>sys_free=17871MB/32213MB</code>. Not a memory ceiling or OOM kill.</li>
<li><strong>Disk space.</strong> ~785 GB free.</li>
<li><strong>Disk health.</strong> <code>Get-PhysicalDisk</code> reports Healthy / OK.</li>
<li><strong>Antivirus.</strong> Windows Security protection history shows no recent actions and no quarantined Claude items. No third-party AV quarantine involvement found.</li>
<li><strong>GPU hardware state.</strong> <code>Get-PnpDevice -Class Display</code> reports Status OK.</li>
<li><strong>Storage Sense.</strong> Enabled but scoped to temp files, Recycle Bin, and Downloads; does not reach package directories.</li>
</ul>
<h2>Secondary issues found along the way</h2>
<p>These may or may not be related, but were observed on the same machine.</p>
<p><strong>1. Package entered <code>Modified, NeedsRemediation</code> state; Repair and Reset both failed.</strong></p>
<p>Before the reinstall, <code>Get-AppxPackage</code> reported:</p>
<pre><code>Status : Modified, NeedsRemediation
</code></pre>
<p>Settings → Installed apps → Claude → Repair returned "We couldn't repair this app. Try again in a bit." Reset returned the equivalent message. <code>Get-AppxLog</code> showed the Register operation completing with <code>result 0x0 (step 4 of 4)</code> and ACLs repaired successfully, yet the status remained <code>NeedsRemediation</code> — the repair reported success without resolving the underlying condition. An <code>error 0x80070015</code> (<code>ERROR_NOT_READY</code>) on notifying the pre-launch service also appears in the deployment log.</p>
<p>Resolved by full removal (<code>Remove-AppxPackage</code>, including <code>-AllUsers</code>) and clean reinstall. Worth noting that a repair which reports success while leaving the package in <code>NeedsRemediation</code> is itself arguably a bug, since it gives the user no signal that a reinstall is required.</p>
<p><strong>2. Cowork VM bundle never downloaded.</strong></p>
<p><code>cowork_vm_node.log</code> logs routine VM client loads going back to 2026-08-21, then from 18:26:55 onward repeats:</p>
<pre><code>[Bundle:status] rootfs.vhdx missing
[Bundle:status] vmlinuz missing
[Bundle:status] initrd missing
</code></pre>
<p>A filesystem search confirms no <code>.vhdx</code> file anywhere on the C: drive, and <code>%LOCALAPPDATA%\Claude</code> contains only a <code>Logs</code> directory — no bundle folder at all. The app repeats the "missing" status without surfacing any error to the user or apparently retrying the download. This is separate from the GPU crash (the Code tab uses its own <code>claude-code</code> binary and does not require the VM), but Cowork is presumably non-functional as a result.</p>
<p><strong>3. Documentation/log-path mismatch.</strong></p>
<p>Community documentation and several GitHub issues describe Windows MSIX installs storing data under <code>%LOCALAPPDATA%\Packages\Claude_<hash>\LocalCache\Roaming\Claude\</code>. On this install that path does not exist at all. Actual locations:</p>
<ul>
<li>Logs: <code>%LOCALAPPDATA%\Claude\Logs\</code></li>
<li>Config and Claude Code binary: <code>%APPDATA%\Claude\</code></li>
</ul>
<p>This cost significant time during troubleshooting. If the storage location changed between versions, the docs appear not to reflect it.</p>
<h2>Notes</h2>
<ul>
<li>The <code>[PreviewContext] Blocked subresource to private-resolving host</code> warning one second before the crash may be relevant or may be incidental — the project under test is served locally, so the block itself is expected behavior.</li>
<li>Exit code 101457950 (0x60C_xxxx range) was not decoded further.</li>
<li>A newer Intel Arc driver has not yet been tested; Dell's update tool reports no update available, though Intel typically ships Arc drivers ahead of OEM packages.</li>
</ul>
<h2>Workaround</h2>
<p>Sessions remain stable if the browser preview / page script step is avoided. All other Code functionality — file edits, command execution, grep, git operations — worked normally right up to the preview step.</p></body></html><!--EndFragment-->
</body>
</html>
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.40609.0.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
_No response_