[BUG] Cowork session crashes with "undefined is not an object (evaluating 'H.type')" after Python PDF generation scripts

Resolved 💬 3 comments Opened Mar 16, 2026 by hiramAcevedo Closed Mar 20, 2026

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?

My Cowork sessions crash with a frontend JavaScript error after executing Python scripts that generate PDF files (using reportlab or RenderCV). This has happened approximately 10+ times across multiple sessions over several weeks while working on a CV generation pipeline.

The crash happens AFTER the script completes successfully — files are generated correctly and persist on disk. The error is a frontend/client-side JavaScript error, not a Python error.

Important: this does NOT only happen in long sessions. In one case, the session was practically new — I had only pasted context from a previous crashed session and asked Claude to generate one PDF script. It executed successfully, and the session crashed immediately. No browser automation, no heavy tool usage, just script execution → crash.

In another case, the crash did happen in a longer session with browser automation. So the trigger is not session length — it's specifically tied to Python script execution that produces PDF files.

This has been happening consistently for weeks (~10+ times). It's not a one-off.

What Should Happen?

The Cowork session should remain stable after Python script execution. The script runs fine and produces valid output — the session shouldn't crash after it.

Error Messages/Logs

Earliest occurrence (conversation: "Update CV skills and build job application pipeline"):
undefined is not an object (evaluating 'H.type')
TypeError: undefined is not an object (evaluating 'pT(H).length')
    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:1635:12376)
    at reduce (native:1:11)
    at vH (/$bunfs/root/src/entrypoints/cli.js:1635:12353)
    at processTicksAndRejections (native:7:39)

Recent crash 1 (long session with browser automation):
undefined is not an object (evaluating 'H.type')

Recent crash 2 (short/clean session — almost no prior context):
undefined is not an object (evaluating 'H.type')

Error: File does not exist. Note: your current working directory is /sessions/happy-admiring-newton.
    at call (/$bunfs/root/src/entrypoints/cli.js:1466:6033)
    at processTicksAndRejections (native:7:39)

The first stacktrace is the most informative: pT(H).length is called inside a reduce in function vH at cli.js:1635:12353. H is undefined at that point. This looks like a null reference in the response processing pipeline — possibly trying to iterate over tool call results or message content blocks where one element is unexpectedly undefined.

Steps to Reproduce

  1. Open a Cowork session with a workspace folder mounted on macOS (Apple Silicon)
  2. Ask Claude to write and execute a Python script that generates a PDF. This crashes with two completely different PDF generation stacks:

Option A — reportlab (direct Python PDF construction):

   from reportlab.pdfgen import canvas
   from reportlab.lib.pagesizes import letter
   from reportlab.lib.colors import HexColor
   c = canvas.Canvas("output.pdf", pagesize=letter)
   # ... build CV with multiple sections, wrapped text, styled elements ...
   c.save()

Option B — RenderCV (YAML → Jinja2 → Typst → PDF):

   rendercv render my_cv.yaml

RenderCV doesn't use reportlab at all — it uses Typst as its rendering engine. Completely different PDF generation pipeline, same crash.

  1. The script executes successfully, the PDF is created on disk and is valid
  2. The session crashes immediately after with "undefined is not an object (evaluating 'H.type')"

Important notes:

  • This crashes with TWO different PDF libraries that share zero code (reportlab vs RenderCV/Typst). The issue is not library-specific.
  • This has crashed both in long sessions (40+ exchanges with browser automation) AND in practically clean sessions where the only action was writing and executing the PDF generation script. Session length is NOT the determining factor.
  • A simple "Hello World" PDF might not trigger it — in my experience it happens with more complex scripts (multi-section CVs, styled text, multiple draw calls). But I haven't tested minimal reproductions specifically because the crash destroys my session and I lose my workflow.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Using Cowork mode via Claude Desktop (latest version as of March 16, 2026). Not using Claude Code CLI directly.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

I spent time debugging this across 3 sessions on the same day and found a pattern, but it's more nuanced than just "long sessions":

CRASH 1 — Long session:

  • 40-60+ exchanges with heavy Claude in Chrome usage (20+ browser tool calls)
  • Python script with reportlab + pypdf imports + shutil.copy
  • Script overwrote an existing file (same filename)
  • Crashed immediately after successful execution

CRASH 2 — Short/clean session:

  • Practically new conversation — only pasted context from previous crash and asked to regenerate
  • NO browser automation at all
  • Just one script execution → crash
  • Same error: "undefined is not an object (evaluating 'H.type')"

NO CRASH — Session 3 (same day, same task):

  • Fresh session
  • Simpler scripts (only reportlab, no extra imports)
  • Unique versioned filenames (_v2.pdf, _v3.pdf) instead of overwriting existing files
  • Minimal stdout output from scripts
  • Generated 3 PDFs successfully with zero crashes

The common thread across all crashes is PDF generation via Python — regardless of which library (reportlab or RenderCV/Typst). Not session length, not browser usage, not a specific library. The mitigations that worked were: unique filenames (no overwrite), simpler scripts, and minimal stdout.

I clicked "Send logs" on at least one of the crashes, so you should have telemetry for this.

All generated files survived both crashes — no data loss, only session loss and my time.

Side note: Cowork conversations don't show timestamps on messages, which makes it impossible to correlate crashes with specific app versions. The earliest occurrence was in a conversation titled "Update CV skills and build job application pipeline" but I can't tell you the exact date because there are no timestamps. Adding dates to messages would help a lot with bug reporting.

area:cowork platform:macos

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗