Web session freezes, unresponsive, opencode at 100% CPU

[mhart]

Description

Running opencode web. There's a particular session that seems to cause this. It was going very slow for a long time, and now when I try to get it to continue it just freezes, making the web server unresponsive (doesn't respond to health pings, etc). In Activity Monitor I can see the opencode process using 100% CPU.

When running with --print-logs --log-level DEBUG this is the final output:

INFO  2026-02-19T22:39:09 +0ms service=tool.registry status=completed duration=1 skill
INFO  2026-02-19T22:39:09 +0ms service=tool.registry status=completed duration=2 task
INFO  2026-02-19T22:39:09 +14ms service=session.prompt status=completed duration=19 resolveTools

And that's where it freezes.

Plugins

No response

OpenCode version

1.2.7

Steps to reproduce

Unclear if this is easily reproducible for anyone else, only seems on one session for me at the moment.

I'm trying to debug further using the source code as we speak. Will update with findings

Screenshot and/or share link

No response

Operating System

macOS 26.3

Terminal

No response

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Opencode is using 100% CPU since sqlite migration when submitting a message #13969: Opencode process using 100% CPU since sqlite migration when submitting a message (server-side 100% CPU)
• Opencode Web - Terminal uses 100% CPU #13899: Opencode Web terminal causing 100% CPU usage (web-related CPU issue)

If your issue is distinct (e.g., triggered specifically by a long-running session hanging at resolveTools), please add details that distinguish it from the above.

[mhart]

Ok, it's freezing on the const sessionMessages = clone(msgs) step.

Infinite recursion or something?

Continuing to debug

[mhart]

The clone call is incredibly expensive. I suspect due to the reference saving mechanism and linear lookup:

https://github.com/remeda/remeda/blob/047c93e314bb9351b3ab93b34ce4b6cf67df7b1d/packages/remeda/src/clone.ts#L80

Replacing it with const sessionMessages = structuredClone(msgs) call directly is much faster. Still takes 1352ms in this case, suggesting a large msgs object.