Read terminal screen buffer programmatically?

[Ram Rachum (cool-RR)]

I'm looking to build a tool that scans the visible terminal content for custom patterns (like ticket IDs, file:line references, etc.) and presents them in a picker UI for quick action.

With legacy conhost, this was possible using ReadConsoleOutputCharacter and related Win32 Console APIs. However, Windows Terminal uses ConPTY and renders in a separate process, so these APIs don't give access to what's actually displayed.

Is there any way to:

1. Read the current visible text from a Windows Terminal pane/tab?
2. Access the text buffer through some API, extension point, or IPC mechanism?

I'm aware of:

• The clipboard workaround (select all → copy → read clipboard) - functional but hacky
• Using tmux in WSL - not ideal for PowerShell/native Windows workflows
• Issue Allow "hyperlink" matching for arbitrary patterns and adding custom handlers  #8849 for custom clickable patterns - would solve my use case but isn't implemented yet

Is there something I'm missing, or is this currently not possible? If not, would this be a reasonable feature request?

[Dustin L. Howett (DHowett)]

Hmm. ReadConsoleOutputCharacter should still work for ConPTY, it just won't be able to address the scrollback. It's important that we keep it working, because Vim for Windows still uses it!

[Ram Rachum (cool-RR)]

Awesome, thank you

[Ram Rachum (cool-RR)]

To clarify my use case: I need to read the console buffer from an external process, not from within the console itself. I have the HWND or can get the PID of the Windows Terminal window. Does ReadConsoleOutputCharacter do that? Is there another way?

[Leonard Hecker (lhecker)]

You need the console HWND which is not exposed by Windows Terminal. It's owned by OpenConsole.exe which may not even be a child process. So, another way is to create a UIA client and read the window using accessibility APIs. (UIA is not particularly well optimized in general, however, so it won't be that fast.)