Skip to content

fix(pi-tui): make debug logging robust on Windows#1903

Open
Caldalis wants to merge 3 commits into
MoonshotAI:mainfrom
Caldalis:fix/pi-tui-debug-redraw-log-dir
Open

fix(pi-tui): make debug logging robust on Windows#1903
Caldalis wants to merge 3 commits into
MoonshotAI:mainfrom
Caldalis:fix/pi-tui-debug-redraw-log-dir

Conversation

@Caldalis

@Caldalis Caldalis commented Jul 19, 2026

Copy link
Copy Markdown

Related Issue

No related issue — found while trying to reproduce #1705 using pi-tui's debug flags, which turned out to have their own bugs on Windows.

Problem

pi-tui has two env-gated diagnostic writers in tui.ts, and both are unsafe — a filesystem failure crashes the whole TUI with no console output (it only surfaces in ~/.kimi-code/logs/kimi-code.log), because an uncaught exception mid-render is caught by the shell crash handler and silently exits:

  1. PI_DEBUG_REDRAW=1 writes to ~/.pi/agent/pi-debug.log via fs.appendFileSync without creating the parent directory. On any machine that has never used ~/.pi/agent, the first full redraw throws ENOENT and the TUI dies. Trace:

ERROR uncaughtException, restoring terminal and exiting error="Error: ENOENT: no such file or directory, open 'C:\Users.pi\agent\pi-debug.log'"

  1. PI_TUI_DEBUG=1 dumps render state to a hardcoded "/tmp/tui". On Windows that path resolves to the current drive's root (e.g. C:\tmp\tui) instead of the real temp location, and the block has no error guard — an unwritable target throws and crashes the TUI the same way.

What changed

  • PI_DEBUG_REDRAW: create the log directory (fs.mkdirSync(..., { recursive: true })) before appending, wrapped in try/catch.
  • PI_TUI_DEBUG: write to os.tmpdir() instead of a hardcoded /tmp,
    and wrap the mkdir/write in try/catch.

Both now follow the "diagnostic logging must never crash the app" convention already used elsewhere in this codebase (e.g. the update-preflight logger, and the sibling terminal.ts write logger). Added regression tests for both: one points HOME at a fresh temp dir (so .pi/agent is missing) and asserts the render loop survives; the other redirects os.tmpdir() and asserts the dump lands in the OS temp dir, not /tmp. Both tests fail without the fix.

Checklist

  • I have read the CONTRIBUTING document.
  • I have linked a related issue, or explained the problem above.
  • I have added tests that prove my feature works.
  • Ran gen-changesets skill, or this PR needs no changeset.
  • Ran gen-docs skill, or this PR needs no doc update.

Caldalis added 2 commits July 19, 2026 12:19
    PI_DEBUG_REDRAW=1 wrote to ~/.pi/agent/pi-debug.log via fs.appendFileSync without ensuring the parent directory existed.
    On a machine that had never written there, the first full redraw threw an uncaught ENOENT and silently killed the whole TUI (no console output at all — the crash only surfaced in ~/.kimi-code/logs/kimi-code.log).
    Create the directory before appending, and wrap the write so a logging failure can never crash rendering.
@changeset-bot

changeset-bot Bot commented Jul 19, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 350f44f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@moonshot-ai/pi-tui Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

The PI_TUI_DEBUG render-dump path hardcoded "/tmp/tui", which on Windows resolves to the current drive root (e.g. C:\tmp\tui) instead of the real temp location,
and it had no error guard an unwritable target would throw and crash the TUI (the same failure mode as the PI_DEBUG_REDRAW logger).
Use os.tmpdir() and swallow filesystem errors, matching the diagnostic-logging convention.
@Caldalis Caldalis changed the title fix(pi-tui): create debug-redraw log directory before writing fix(pi-tui): make debug logging robust on Windows Jul 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant