Ctrl+C bypasses the app's exit path, leaving the terminal cursor hidden after the process terminates

[matt-edmondson]

What's wrong

SpectreConsoleProvider.ReadInputAsync() has a branch that special-cases ConsoleKey.C + ConsoleModifiers.Control as if it will come back as ordinary input from Console.ReadKey(true). By default it won't: .NET's Console treats Ctrl+C as a process interrupt (SIGINT / CancelKeyPress) and terminates the process before Console.ReadKey ever sees it, unless Console.TreatControlCAsInput has been set to true.

Neither Console.TreatControlCAsInput = true nor a Console.CancelKeyPress handler exists anywhere in TUI.Core, TUI.App, or TUI.CLI.

Failure scenario

UIApplication.RunAsync() hides the cursor on startup and only restores it (ConsoleProvider.SetCursorVisibility(true)) in its finally block on normal shutdown. Pressing Ctrl+C — the near-universal terminal "quit" convention — terminates the process at the runtime/OS level, skipping RunAsync's finally entirely. The user is left with an invisible cursor in their terminal after the process exits, until they run another program that resets terminal state or manually reset it.

Suggested fix

Either:

• Set Console.TreatControlCAsInput = true while the app runs (so the existing Ctrl+C branch in ReadInputAsync becomes reachable) and restore the previous value in finally, or
• Register a Console.CancelKeyPress handler that sets e.Cancel = true, restores terminal state (cursor visibility, etc.), and triggers Shutdown().

Acceptance criteria

Pressing Ctrl+C while the app is running exits cleanly through the normal shutdown path, and the terminal cursor is visible again after the process ends.

[matt-edmondson]

Triage

Category: Bug
Priority: Medium
Area: TUI.Core — SpectreConsoleProvider.ReadInputAsync(), UIApplication.RunAsync()

Ctrl+C is the near-universal terminal quit convention, and taking it leaves the user's cursor invisible after the process exits — terminal state damage that outlives the program and that most users will not know how to undo. Medium because it is recoverable and does not affect correctness while running, but it is a poor impression for a TUI library specifically, where owning terminal state is the core responsibility.

Worth noting the existing ConsoleKey.C + ConsoleModifiers.Control branch in ReadInputAsync is currently dead code — .NET will not deliver Ctrl+C through Console.ReadKey unless TreatControlCAsInput is set. So there is already an intent in the codebase to handle this; the enabling half was never wired up.

Related: #109 (Critical) and #111 in this repo are also in UIApplication's loop and lifecycle. Independent of this one, so it can be fixed in any order.

Not covered by an open PR.

Suggested next step: of the two options, the CancelKeyPress handler is the more robust — it restores terminal state even if the app is not sitting in ReadInputAsync at the time, whereas TreatControlCAsInput only works while input is being read. Whichever is chosen, make sure the previous value is restored in finally, and consider handling SIGTERM for the same reason.

---

Generated by Claude Code