What should the transcript ideally capture when a TUI application starts in PowerShell? #28296

Thank you rhubarb-geek-nz for this thorough analysis — it directly shaped how I proceeded.

You're right on all three points, and point 2 is the crux: you can't know in advance how a console program will interact (stdin line reads, raw mode, or opening CONIN$/CONOUT$//dev/tty directly), so no pipeline-level transcript can ever be complete. Your console-logger is exactly the proof that the pseudo-terminal approach works on Windows: create a ConPTY for the child, and you can both display and capture the character stream.

So rather than leaving Start-Transcript as a best-effort text log, I've drafted an RFC that adds a strictly additive recording capability:

• New switches on Start-Transcript: -RecordTerminal, -RecordingFormat (Asciicast | Gif | WebM | Mp4), -RecordInput (default off, since it can capture secrets that are typed but never echoed), and -RecordIdleTimeLimit. Everything about the existing text transcript stays exactly as it is.
• Capture happens host-level: the console host attaches native/TUI children to a ConPTY (Windows) / PTY (Unix) pair, proxies the stream to the real terminal, and tees it with timestamps — the same mechanism as your console-logger and script(1), just inside the host so it's transparent for every invocation. (A PSGallery module can't transparently intercept CONIN$/CONOUT$//dev/tty traffic without wrapping every call site.)
• Open format as source of truth: recordings are written as asciicast v3 .cast files, so they replay with asciinema play and interoperate with the existing ecosystem. Video is a render product of the stream: animated GIF via a built-in renderer, WebM/MP4 via ffmpeg when available (this is the "save as video" ask for training/docs/bug-report scenarios).
• Group policy extension for the audit use case — the RHEL tlog/SSSD/PAM precedent — via EnableTerminalRecording, RecordingFormat, RecordingOutputDirectory.

Regarding your recommendation to leave Start-Transcript as it is and build a Start-InteractiveTranscript — I took it seriously and included it in the RFC as Alternate Proposal #2. The counter-argument is discoverability and the compliance configuration story: recording is far more likely to be used and governed correctly as a mode of the one cmdlet everyone already knows and audits already configure. The RFC explicitly notes that the same specification could ship under a separate cmdlet name if the Committee prefers.

Everything is up for review:

• RFC draft PR: RFC: Terminal Session Recording in Start-Transcript PowerShell-RFC#421
• Implementation tracking issue: Feature Request: Add terminal session recording to Start-Transcript (capture TUI applications, export to video) #28353

I'd genuinely value your review of the RFC — especially the capture pipeline section, since you've already built a working version of that part.