[Bug]: Error Toast/Sonner broken

[OmkarBhat16]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Not sure how to reproduce completely. But here is what I think happened.

1. I exhausted my 5 hour limit on codex yesterday. Got the expected error toast and closed the program yesterday.
2. Updated from 0.0.27 to 0.0.28 today.
3. Opened the thread and the error toast is broken and not removable. The cancel button does nothing.

Expected behavior

The error toast should fade away after a bit and instantly when the X is pressed.

Actual behavior

Error toast stays on the top of the screen and is not removable after refreshing and restarting the application.

Impact

Cosmetic issue

Version or commit

v0.0.28 , fda6486

Environment

Omarchy 3.8.2,Linux 7.0.11-arch1-1,Hyprland 0.55.3 (Wayland),bun 1.3.5, node 25.2.1

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[Tyler-Petrov]

This bug can be reproduced by dragging an image file into chat, as that's not allowed and a toast will be displayed

[MahmoudHilani]

same thing on windows

[KarstenKreh]

Same here on Windows 11, T3 Code desktop. The error banner sits in the thread and the X does nothing, and it survives restarting the app.

Two things from my side:

• It is not purely cosmetic. The banner covers the top of the message it belongs to, so part of the text I was reading is hidden.
• The message itself is unreadable for a normal user: [ede_diagnostic] result_type=user last_content_type=n/a stop_reason=tool_use. That is internal harness state, nothing I can act on. A plain sentence plus a "details" toggle for the raw string would help a lot.

Note: AI-written comment, posted on Karsten's instruction.

[t3dotgg]

Thanks for the detailed report. We believe this is fixed by PR #3899, PR #6123, and PR #5557.

The original stuck error banner has a specific repair: dismiss now records the thread/error pair and forces a rerender instead of merely clearing a local shadow and exposing the persisted error again. The malformed narrow alert layout was fixed separately. The later concrete diagnostic-string complaint is also addressed by filtering ede_diagnostic errors. The latest failure comment predates the dismissal and diagnostic repairs.

I'm closing this as fixed as part of an automated pass on all open issues. If this still happens in a current build that includes PR #3899, PR #6123, and PR #5557, please reply with the T3 Code version and fresh logs or reproduction details, and we can reopen it.