#1647

fix(tui): allow a longer startup when launching through go run

Openaniyow07wants to merge intofrom

Fixes #1191

A first go run on a cold cache can take longer than the 10 second startup limit, so the TUI fails to launch.

  • go run launches now get 300 seconds. Packaged binaries keep 10 seconds.
  • This includes Windows, which has its own 10 second limit on the child connecting.
  • On Windows, a child that exits early now fails right away instead of waiting out the limit.

Tested with real cold go run: Windows went from failing at 10s to connecting at 47.7s. Linux is ready at 18.9s, measured with a small Go driver rather than the Python launcher. The new tests have only run on Windows.

Activity

5
greptile-apps[bot]4d ago

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Source launches now get longer to compile before the TUI must answer.

  • Source-based TUI launches get more time to connect and finish the handshake.
  • Windows reports when the TUI child exits before connecting.

No actionable issues were found. Tests were not run during this review.

Reviews (1) · Last reviewed commit: "fix(tui): apply the go run startup limit..." · Reviewed by Greptile

yoni-at-strix3d ago
strix-security[bot]3d ago

Strix Security Review

✅ No open security findings.

PR summary: This PR lets the TUI launched via `go run` wait up to 300 seconds for its child process to compile, connect, and complete the protocol handshake, while packaged binaries keep the 10-second startup and connect limits; on Windows the accept loop now also polls for early child exit so a failed launch fails immediately.

Review summary

Reviewed the timeout-plumbing changes in the TUI launcher. The PR threads an optional startup budget from GoTuiRuntime.run through sidecar.launch_tui_process into both the Windows loopback accept and the backend protocol handshake, and adds a bounded poll loop so an early child exit fails fast. I traced each new value to its origin: the 300-second budget is derived from cwd is not None, which is set only for go run in a source checkout, so packaged launches keep the existing 10-second limits. The authentication path, socket lifecycle, and frame-size validation are untouched, the poll loop enforces an absolute deadline, and the handshake timeout can only delay a wait that still requires a valid protocol-ready frame before any privileged action is enabled. No new attack surface, missing check, or removed control was found.

Review 1 on this PR · a6a70f3 · requested Nov 4 23:24 UTC by @yoni-at-strix


Reviewed by Strix Re-run review · Configure security review settings