[BUG] Windows desktop: main.log stops writing at ~10 MiB with no rotation - main-process logs are permanently lost on long-lived installs (1.26832.0.0)

Summary

On Windows, the desktop app's main.log stops being written once it passes ~10 MiB. There is no rotation, no .old/.1 file, and no final line saying logging stopped — it just ends and nothing is ever appended again. On a long-lived install this means main-process logging is permanently dead, and neither the user nor a maintainer reading the file can tell that anything is missing.

cowork_vm_node.log does the same thing, independently and on a different date.

Evidence

%APPDATA%\Claude\logs\
  main.log             10,486,118 bytes   last written 2026-06-24 23:20:37   <- frozen
  cowork_vm_node.log   10,485,949 bytes   last written 2026-07-19 06:28:06   <- frozen
  claude.ai-web.log     1,774,963 bytes   last written 2026-08-09 00:35:02   <- still live
  unknown-window.log      905,794 bytes   last written 2026-08-09 00:36:49   <- still live
  ssh.log                  86,923 bytes   last written 2026-08-09 00:28:07   <- still live

10 MiB = 10,485,760 bytes. Both frozen files sit a few hundred bytes past it (main.log +358, cowork_vm_node.log +189); every file under the threshold is still current as of today.

Two details that rule out the obvious alternative explanations:

• The two files froze a month apart — main.log on 2026-06-24, cowork_vm_node.log on 2026-07-19. So this isn't "an app update on some date changed the log path"; it's two independent writers each hitting the same ceiling whenever they happen to reach it.
• No rotated copy exists anywhere. Get-ChildItem -Force on the logs directory shows no hidden or .old/.1 files, and a recursive sweep of the whole user profile plus C:\ProgramData for main*.log returns exactly one Claude file — the frozen one. Nothing was moved aside; writing simply stopped.

main.log ends on a complete, CRLF-terminated record and then stops, with no truncation notice:

2026-06-24 23:20:37 [error] Sentry caught: {
  eventId: 'd1a38db6ba594c0fa2a83b6c0c716e4a',
  type: 'Unknown',
  value: "'Utility' process exited with 'killed'",
  stack: undefined
}

The cap isn't enforced to the byte — the file was already ~174 bytes past 10 MiB before that last 184-byte record was appended, and the record before it is 20 hours earlier. But after that point, nothing.

Why this is worth fixing

There have been a number of Windows GPU-process crash reports recently (#80444, #81698, #81836, #82967, #83478). In every one of them the useful diagnostic is the main-process line — GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: ... } — which is what those reporters were able to paste.

On this install that line cannot be produced for anything after 2026-06-24, because main.log had already stopped. The renderer logs are still recording fine (unknown-window.log has WebGL INVALID_ENUM: getInternalformatParameter / EXT_color_buffer_float is not enabled / powerPreference ... requestAdapter() / CONTEXT_LOST_WEBGL clusters on 2026-08-07 and 2026-08-09), and the Crashpad reports directory holds no pending report — so the renderer side says "something happened here" and there is no main-process record to pair it with.

I'm not claiming those WebGL clusters caused a crash on this machine — on 2026-08-09 the same chain was followed by half an hour of normal logging on a healthy install. The point is narrower: when a user on a long-lived install does hit a crash worth reporting, the file you'll ask them for has been silently empty for weeks.

Expected behaviour

1. Rotate main.log (e.g. main.log → main.1.log) instead of stopping at ~10 MiB.
2. If rotation isn't wanted, write one final record stating the cap was reached, so the gap is visible instead of looking like "the app logged nothing".
3. Same for cowork_vm_node.log.

Environment

• Claude desktop 1.26832.0.0 (MSIX, Claude_1.26832.0.0_x64__pzs8sxrjxfjjc)
• Windows 11 Home 10.0.26200 (zh-CN), 64-bit, 32 GB RAM
• NVIDIA GeForce RTX 5070 Laptop GPU (driver 32.0.15.8205) + Intel UHD Graphics (driver 32.0.101.7076)
• Disclosure in case it matters: the MSIX package is installed on a non-system volume — C:\Program Files\WindowsApps\Claude_... is a junction to D:\WindowsApps\Claude_... (Windows "install new apps on another drive"). The log files themselves are in the normal %APPDATA%\Claude\logs location on C:, so I don't believe this is related, but noting it rather than have it come up later.

Related

#80444, #81698, #81836, #82967, #83478 — Windows GPU-process crash reports whose diagnosis depends on the main-process log this bug destroys.