Can I use a TV for a computer monitor? Yes, and plugging it in quietly resizes the overlay window every app on your PC is drawing.

Yes. Any modern TV with an HDMI input works as a display. Windows and macOS treat it as monitor 2 the moment you extend the desktop onto it. The SERP answer stops there, which is fine for most people. The part that matters for anyone running automation software on the PC is that plugging the TV in also changes what Windows reports for the virtual screen bounding box (SM_XVIRTUALSCREEN, SM_YVIRTUALSCREEN, SM_CXVIRTUALSCREEN, SM_CYVIRTUALSCREEN), and any overlay or full-screen tool that sizes itself by those metrics will now extend onto the TV.

Terminator's action overlay window is created at crates/terminator/src/platforms/windows/action_overlay.rs lines 287 through 291 by calling GetSystemMetrics(SM_XVIRTUALSCREEN), GetSystemMetrics(SM_YVIRTUALSCREEN), GetSystemMetrics(SM_CXVIRTUALSCREEN), GetSystemMetrics(SM_CYVIRTUALSCREEN), then passing those four values to CreateWindowExW with the WS_EX_TRANSPARENT flag. The overlay is one HWND that covers every display the OS can see. Plug in a 4K TV to the right of a 2560-wide laptop and SM_CXVIRTUALSCREEN returns 6400. The overlay HWND is now 6400 pixels wide. Running Grep on the open-source repo reproduces this verbatim.

So a human glancing at the screen can tell what the AI agent is currently doing. The overlay says things like 'Clicking Chrome -> Subscribe' or 'Typing on email field'. Each action method (UIElement.click, UIElement.type_text, UIElement.press_key in element.rs) wraps itself in an ActionOverlayGuard RAII type defined at action_overlay.rs line 242. The guard calls show_action_overlay in its constructor and hide_action_overlay in its Drop impl, so the banner is always in sync with whatever step is running. On a single display this is a small status bar. With a TV as display 2, the same status bar extends onto the TV, which makes it a perfectly readable dashboard from further away.

Set the environment variable TERMINATOR_ACTION_OVERLAY=0 (or 'false' or 'off', all case-insensitive) before launching your automation. The check lives at action_overlay.rs line 38. When the var is set, ACTION_OVERLAY_ENABLED flips to false, show_action_overlay becomes a no-op, and nothing paints on either display. Your automation still runs identically, you just lose the status banner. On Windows PowerShell: $env:TERMINATOR_ACTION_OVERLAY='0'; python run.py. On Linux/macOS: TERMINATOR_ACTION_OVERLAY=0 python run.py.

No. The overlay window is created with WS_EX_TRANSPARENT in its extended style flags, which means every mouse event passes through to whatever is behind it. It is also created with WS_EX_NOACTIVATE, so it never steals focus. You can keep working on the laptop or interact with the TV as a touch display (if it is one) while the banner is painting across both. The overlay is strictly cosmetic output, not input capture.

Two constants in action_overlay.rs handle that. OVERLAY_CHANGE_COOLDOWN_MS is 100 milliseconds, so if two actions fire within 100ms of each other, the second one does not trigger a fresh show/hide cycle. MINIMUM_DISPLAY_MS is 300 milliseconds, so once the overlay is visible it stays visible for at least that long even if the action completes sooner. Together those mean a burst of fast clicks shows up as a continuous status banner on the TV, not a strobe.

Yes. The per-element highlighter in crates/terminator/src/platforms/windows/highlighting.rs will by default call scroll_into_view on whatever it is about to highlight, to make the highlight visible. During a recording that is exactly what you do not want, because it creates a synthetic scroll event that was not part of the user's real workflow. Call set_recording_mode(true) (highlighting.rs line 60) before you start capturing. It flips a global AtomicBool that the highlight path reads, and scroll_into_view is skipped for the duration. Call set_recording_mode(false) when you are done.

The overall story is the same, but the concrete metric names differ. macOS reports the equivalent bounding box through NSScreen.screens.reduce over the .frame property, not GetSystemMetrics. Terminator's macOS engine does not ship the same SM_CXVIRTUALSCREEN-style action overlay today (action_overlay.rs is Windows-specific; it sits in src/platforms/windows/). The element highlighter has a cross-platform path, but the full-screen banner is Windows-only at the moment. On macOS you still get per-monitor screenshots via the capture_monitor_by_id path described in the companion guide.

They are complementary. The Monitor struct at crates/terminator/src/lib.rs line 274 is the read side: it tells your automation code what displays exist, where they are, and at what scale factor. The action overlay in action_overlay.rs is the write side: it uses the OS-level virtual screen metrics to draw visible feedback across every display, no Monitor struct required. You can run one without the other, or combine them (for example: enumerate monitors, decide the TV is display 2, then set TERMINATOR_ACTION_OVERLAY=0 if the TV is is_primary=false and you know it is being used for video).

Taskbar and wallpaper extension are OS-level affordances: Windows takes care of them, and every app sees them passively. The action overlay is app-level: it is drawn by Terminator specifically because Terminator wants to give the user a live status readout. The reason it stretches onto a TV plugged into the PC is that Terminator sizes its overlay window by the exact same virtual-screen metrics the OS uses, so when the OS says 'the desktop is now 6400 by 2160', the overlay says yes to that without any special-case code. This is why it just works when you plug in a TV and just stops working (correctly) when you unplug it.