Windows support?

[amugoodbad229]

Current behavior

Currently it is for linux and macos.

Requested change

Windows support.

Reason

There is no windows support.

Does this change UI, interaction, workflow, or product direction?

No

Impact details

No response

Contribution intent

• I intend to open a PR for this issue.
• I understand this does not mean the issue is approved.

[ogulcancelik]

it's possible to run herdr on wsl windows atmt, but native windows will require pipes which is a big work, but planned :)

[samuelpatro]

@ogulcancelik did some magic, looks like it works but needs even more magic and testing #138

[jwvanderbeck]

If I may ask, just from an educational standpoint, what is meant by "will require pipes"? Is this something to do with the terminals on Windows or something else? I use the Warp terminal which runs bash.

[ravenwits]

@samuelpatro Your PR looks solid, I think this is exactly the kind of Windows support herdr needs. A clean platform abstraction with platform::net and ConPTY integration. The VT input re-encoding approach is also smart. Hopefully we can test it pretty soon on Windows too. Thanks.

[ravenwits]

If I may ask, just from an educational standpoint, what is meant by "will require pipes"? Is this something to do with the terminals on Windows or something else? I use the Warp terminal which runs bash.

@jwvanderbeck On Windows, the "pipes" issue refers to how terminal emulators communicate with the shell process. For example Linux/macOS uses a well established, mature POSIX system PTYs (pseudo-terminals) while Windows uses conhost.exe(the old console host) which doesn't expose a PTY interface. Microsoft introduced ConPTY (ConPTY = Console Pseudo-Terminal) in Windows 10 to bridge this gap.

@samuelpatro is essentially porting a Linux-first architecture to Windows different terminal model. It's doable (WezTerm, Alacritty, and Ghostty all solved this), but requires deep platform-specific work as @ogulcancelik suggeested.

P.S ConPTY is relatively new and has known quirks like latency, incomplete VT sequence support, and edge cases with alternate screen buffers (used by TUI apps like superfile, lazygit, vim). I've tested the PR and those TUI apps does not properly render especially on resize or scroll events inside Herdr as Windows uses different Unicode width tables than POSIX. Box-drawing characters, emojis, and CJK characters may be measured differently, causing layout corruption.

[ogulcancelik]

@ravenwits thanks for the help on the explanation :)

conpty and exact compatibility is my main concern here. and i assume many devs use wsl these days. but if native windows is really wanted, i will take a look at that myself and the pr, and may release under windows beta, so i won't be able to guarantee feature parity/quality :/

[jwvanderbeck]

I know a lot of people use WSL but there are also a lot of us that prefer to work native in Windows. I don't want to have to deal with mounting drives, and a whole different shell, etc. May sound petty but WSL is just an extra layer of friction when I'm not doing ANYTHING else in it.

[samuelpatro]

If I may ask, just from an educational standpoint, what is meant by "will require pipes"? Is this something to do with the terminals on Windows or something else? I use the Warp terminal which runs bash.

@jwvanderbeck On Windows, the "pipes" issue refers to how terminal emulators communicate with the shell process. For example Linux/macOS uses a well established, mature POSIX system PTYs (pseudo-terminals) while Windows uses conhost.exe(the old console host) which doesn't expose a PTY interface. Microsoft introduced ConPTY (ConPTY = Console Pseudo-Terminal) in Windows 10 to bridge this gap.

@samuelpatro is essentially porting a Linux-first architecture to Windows different terminal model. It's doable (WezTerm, Alacritty, and Ghostty all solved this), but requires deep platform-specific work as @ogulcancelik suggeested.

P.S ConPTY is relatively new and has known quirks like latency, incomplete VT sequence support, and edge cases with alternate screen buffers (used by TUI apps like superfile, lazygit, vim). I've tested the PR and those TUI apps does not properly render especially on resize or scroll events inside Herdr as Windows uses different Unicode width tables than POSIX. Box-drawing characters, emojis, and CJK characters may be measured differently, causing layout corruption.

Now i want to migrate to unix after this response 🚄 😄

[ravenwits]

I already use Linux/macOS but keeping the exact same workflow everywhere is hard to give up.
Also my RTX card would feel personally offended if I abandoned Windows completely, considering we are moving towards a local LLM trend 😄

Herdr's agent aware approach with the local agent network sounds genuinely interesting to me. I don't have much experience with pipes yet, but the idea of letting multiple local agents/tools communicate in a more composable way feels like a pretty natural direction for developer tooling.

[samuelpatro]

@ravenwits soon we will make our rtx cards as ai local servers 😂

@ogulcancelik maybe add windows support but mark it as preview or alpha? Like people then can report issues, if its works or minimal specs, but my PR worked there was some delay but it was working pretty well for first run

looks like Zed editor is going similar way to spawn CLI agents https://zed.dev/blog/terminal-threads

[sanirudh17]

Any tentative release timeline for windows?

[ogulcancelik]

i don't have a timeline for native windows atm sorry! i pinned this issue to track :)

[Rahmyeon]

I don't know the guy but, there was someone who helped port zellij to windows, I believe reaching out to him I believe should give some insight in to how do it. I won't at him and I don't believe he will respond but divens helped with that and he should have some knowledge on how to get it to work.

[azinsharaf]

I don't know the guy but, there was someone who helped port zellij to windows, I believe reaching out to him I believe should give some insight in to how do it. I won't at him and I don't believe he will respond but divens helped with that and he should have some knowledge on how to get it to work.

"divens" (gh usrname) added windows support to zellij.

[samuelpatro]

i migrated to mac, then for me issue has been solved 😀

if you guys need help with testing on windows or something ping me later :)

[ogulcancelik]

hey everyone, please take a look at https://herdr.dev/docs/windows-beta/ !

you can use this discussion for feedback but please be aware, native windows is hard to support so beta period will be a test for me to understand and analyze feasibility moving forward. expect bugs and not 1:1 feature mapping with unix herdr.

[iki]

You can also install herdr using mise-en-place:

# Linux/Mac [sh]
mise use -g herdr

# Windows (preview) [cmd]
mise use -g herdr[prerelease=true]@preview-

# Windows (preview, install immediatelly without default security 1 day delay) [cmd]
mise use -g herdr[prerelease=true,install_before="0d"]@preview-

EDIT: Updeted the Windows version prefix to preview- to skip stable releases that miss the Windows binary.

[gadgj]

Hi @ogulcancelik, thanks a lot for the Windows beta — it’s great to see herdr running on Windows.

I have a feature request around terminal notifications and BEL:

Would it be possible for herdr to emit BEL (\a) to the outer terminal when certain events happen (e.g. agent finishes, notification-worthy events, etc.)?

The reason is that terminals like Windows Terminal use BEL as the trigger for their own notification system (tab highlight, taskbar badge, etc.). This applies not only to native Windows shells, but also to WSL sessions running inside Windows Terminal — as long as BEL reaches the outer terminal, the notification UI works.

Right now, herdr provides its own sound/toast‑style notifications, but the outer terminal never sees BEL, so:

Windows Terminal cannot highlight tabs or show taskbar badges

WSL sessions inside Windows Terminal also cannot benefit from terminal‑level notifications

Why BEL support in herdr would be very useful

It lets users rely on the terminal’s native notification UX instead of a separate channel

It works for both native Windows shells and WSL inside Windows Terminal

It removes the need for a special herdr --remote from the Windows binary mode — as long as herdr can emit BEL to stdout/stderr at the right moments, the terminal can do the rest

Even a simple, configurable option like “emit BEL on notification-worthy events” would already unlock a lot of workflows.

I’d be very happy to test any experimental implementation of this. Thanks again for pushing on Windows support — it’s already very promising.

[gadgj]

Hi, @ogulcancelik

I’ve implemented the feature in PR #626, which adds support for emitting terminal bells on agent notifications.

The real scenario is:

Running herdr inside Windows Terminal — either in WSL or in an SSH session to a remote Linux server — and letting Windows Terminal show its native attention indicators (bell sound, tab flash, taskbar flash) when an agent’s state changes.

Windows Terminal already reacts to BEL (\a) for these notifications, but herdr currently does not forward BEL to the outer terminal.

PR #626 implements optional BEL emission on notification‑worthy events, which enables Windows Terminal’s built‑in UX to work properly in these cross‑platform setups.

Since the PR was automatically closed, could you please consider reopening it so we can continue the discussion and move the implementation forward?

I’m happy to adjust anything if needed. Thanks for your time!

[gadgj]

Hi @ogulcancelik and @kenigteh — thanks again for the discussion.

I’d like to add one more clarification regarding PR #626.

Besides enabling Windows Terminal’s native attention indicators (bell sound, tab flash, taskbar flash) when running herdr inside WSL or SSH sessions, the implementation also addresses the same underlying limitation described in Issue #153 — namely, that BEL emitted inside a herdr pane never reaches the outer terminal, so the host terminal cannot trigger its own attention mechanisms (e.g., Dock bounce on macOS) .

Issue #153 proposes an opt‑in mechanism for forwarding a single BEL to the outer terminal when a background pane needs attention .
PR #626 implements this exact behavior in a cross‑platform way, without changing defaults.

So the PR not only solves the Windows Terminal scenario, but also provides a working solution for the macOS Dock‑bounce use‑case described in #153

[jwvanderbeck]

Microsoft recently released coreutils for Windows. I"m not sure if that changes anything or not for this, but wanted to mention it since it brings a lot of bash style commands directly to Windows Terminal.

[gadgj]

Hi, I wanted to share an update on my use case.

With the new plugin system in herdr 0.7.0, I was able to implement a plugin that sends a BEL (\a) signal to Windows Terminal when the agent’s state changes. This works perfectly when I SSH directly from Windows Terminal into the Linux server and run herdr there — Windows Terminal flashes the tab and taskbar as expected.

However, this approach still does not work when I use:

herdr --remote

from inside Windows Terminal’s WSL environment.
In that setup, the plugin cannot deliver BEL to the outer Windows Terminal session, so tab flashing / taskbar flashing does not happen.

Because of this limitation, the only reliable way to get Windows Terminal notifications from a remote herdr session is still the behavior implemented in PR #626. That PR enables herdr to forward BEL to the outer terminal correctly, even when the client is running inside WSL.

So although plugins solve the problem for direct SSH usage, they cannot replace the functionality provided by PR #626 for the WSL → herdr --remote workflow.

[bkntr]

I'd like that as well

[jwvanderbeck]

So my first experience with herdr on Windows wasn't great :) I was in a session with Claude, waiting on it to replay and just as it started to, I was dropped out of herder with a message something about losing connection to the server. I don't recall the specifics, it's early morning. I tried re-attaching and it simply attached to an empty session.

This is all run locally on my machine, so I don't see how it is possible to lose connection.

[StefanKoell]

Looks like Windows on ARM64 is not supported yet 😔

[lhs-12]

I'm a Linux user but curious — has anyone tested Herdr in MSYS2 (a POSIX layer on Windows)? How well does it work there in terms of compatibility and overall experience?