mirror of
https://github.com/anomalyco/opentui.git
synced 2026-04-25 13:06:00 +03:00
[GH-ISSUE #528] bug: terminal is not properly reset if the process terminates abruptly. #141
Labels
No labels
bug
core
documentation
feature
good first issue
help wanted
pull-request
question
react
solid
tmux
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/opentui#141
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @rwese on GitHub (Jan 15, 2026).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/528
Currently when an OpenTui application crashes, exits unclean, the terminal does not properly respond to escape sequences.
I gave the ai a shot to fix it, since I only barely know zig.
If this is close to what is needed I will clean this up, but might need some guidance.
Before fix:
https://github.com/user-attachments/assets/cc992215-4123-4814-9bfe-172c643a3663
After fix:
https://github.com/user-attachments/assets/c09b1621-348e-43de-ac4e-8000f5f93192
Commit/Changes:
github.com/rwese/opentui@3b918893d2@kommander commented on GitHub (Jan 16, 2026):
The additionally handled signals make sense.
As for the exit handler, it did that before, but it was interfering with effect.ts shutdown and the consense was that shutdown should be handled on application level and the application has to call
renderer.destroyproperly.Similarly for error handling, if for an unhandled error opentui decides to destroy the renderer or reset the terminal, but the application wants to handle the error and move on, the app would be broken.
@rwese commented on GitHub (Jan 16, 2026):
I've tried to clean it up and simplify. Now it does listen only on Exit, which should be the very last event bun gives us.
github.com/rwese/opentui@3ebe2ad385Another way to implement this, without breaking any other handling, which applications may already employ, would be to expose it as a function which applications may use.
Maybe I am just not well versed in how bun vs zig vs terminal emulators work..
What i have forgot to mention, i run into this problem frequently with opencode. Everytime when bun fails to install a plugin, read: when i break something again, the
opencodedies and the terminal is borked. I resorted to useopencode <log etc.>; resetto get around this.@kommander commented on GitHub (Jan 16, 2026):
Cool. The
renderer.destroy()method is responsible for terminal cleanup and should be the method called by applications for shutdown.I think opencode needs proper
uncaughtErrorhandling then and callrenderer.destroy()before it exits.@rwese commented on GitHub (Jan 16, 2026):
I will look at the way opencode does it and, if it still happens, attempt a fix there.
When you consider this a won't fix, or unrelated issue, we can close this issue.
@kommander commented on GitHub (Jan 17, 2026):
I would add the additional default signals to handle at least.
@simonklee commented on GitHub (Feb 4, 2026):
Are we missing something to close this issue @kommander ?
@kommander commented on GitHub (Feb 5, 2026):
@simonklee we could document the use of
renderer.destroyproperly and point out that it is up to the app to call it and that opentui does not do all the cleanup on process.exit, to give the app more control. There was a discussion about this in another issue. It only handles the signals that can be overridden via renderer constructor options.