Repository navigation
TUI deadlocks when answering a held peer message (Allow/Deny) #1099
Description
Found in the 2026-09-28 code audit (finding N-4).
Where: internal/tui/peer_messages.go:122-125, called synchronously from resolvePermissionWithReason at internal/tui/model.go:4402. Sink wired at internal/tui/run.go:34-45; coalesce.go:59-68 forwards to program.Send.
Problem: The decide closure calls m.runtimeMessageSink(peerDecisionMsg{...}) inside Update. In bubbletea v2.0.9 Send blocks on the unbuffered p.msgs channel, and the only reader is the event loop, which is currently running Update. Pressing Allow or Deny on a held cross-session message hangs the program, and Ctrl+C queues on the same channel. Tests install a capturing sink (peer_messages_test.go:135, :181), so they cannot see it.
Suggested fix: return a tea.Cmd that yields peerDecisionMsg instead of calling the sink from Update. Consider a debug guard against sink calls on the Update goroutine.
Tests: a regression test that drives Allow/Deny through a real tea.Program (or a blocking sink) rather than a capturing sink.
Activity
Vasanthdev2004 commentedon Oct 12, 2026
Confirmed on main (
bb3346a8).decideruns fromresolvePermissionWithReason, the key handler, so it runs insideUpdate. It callsruntimeMessageSink(peerDecisionMsg{...}), which for any non-text message goes straight through the coalescer toprogram.Send, and that waits on the unbuffered channel the event loop reads. #883 (not merged yet) adds an ordered forwarder for the same freeze on the peer service's held-release callback, but this path doesn't go through it either. Approving.Shape: return the decision from the permission resolution as a
tea.Cmdinstead of calling the sink, which is the Bubble Tea way to emit a message fromUpdate. The regression test should drive Allow and Deny through something that blocks the wayprogram.Senddoes, either a realtea.Programor a sink that blocks untilUpdatereturns; the capturing sinks in the current tests can't see it.