upvote
Something similar has been happening to me with Ghostty, but there is no error message or link and it only happens when Claude uses it's interactive questions interface.

It becomes completely unresponsive to any input except scrolling. I can't select options or even cancel out.

(I am in no way implying this is related to Bun)

reply
I run Ghostty and Claude Code on a work macbook and I haven't seen this yet.

I actually used to have issues with run away memory leaks causing my computer to hang which often required a reboot to recover from. I haven't experienced that in a couple of weeks now. Too early to say just yet but I think its definitely possible that the rust port fixed a bunch of memory leaks that have tangibly improved the experience atleast for me.

reply
What makes you think it's a segfault? Does your shell print "Segmentation fault"? If so, you should be back at your shell and you should be able to recover the tab by typing 'reset' + enter (even if you can't see anything as you're typing it).

If nothing prints "Segmentation fault", this just sounds like a hang

reply
I just had this happen today. It was indeed a segfault.

From what I could tell it looked like it was in JS code that had been JIT compiled. I haven't attempted to troubleshoot further beyond setting all my future Claude Code instances to pipe their stderr to disk so that I don't lose the stack trace next time.

reply
Bun does not have its own JIT compiler. Bun uses JSC made by Apple. So your blame should be directed to Apple.

And I can believe you because I’ve seen JavaScript-heavy Safari tabs crash.

reply
Same experience I have with bun in general. As an idea, it's the absolute best js runtime by a very large margin, but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)
reply
> but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)

In Chrome or Firefox, a segfault is usually automatic CVE and in most cases a bounty of thousands of dollars…

reply
Segfaults were a thing with the Zig version. Purely based on the fact it's a line by line translation of the Zig code to unsafe Rust, all the Zig code that caused segfaults is going to also cause segfaults in the Rust version. The Rust code won't fix it until they get to the point of refactoring it into idiomatic and memory safe Rust.
reply
But if the segfaults are new that implies it’s from the LLM no?
reply
Who said they're new? Also, you can encounter new segfaults in a codebase just by executing code paths you haven't seen before.
reply