Influxx runs natively on macOS, Windows, and Linux, and we didn't get there by compiling one codebase three times and hoping for the best. Each platform hid its own category of problem that the other two simply don't have: Windows fights your own installer and command-line ergonomics, Linux assumes a display that isn't always there, and macOS — the smoothest of the three — still runs its own signing gauntlet before a stranger's machine will open the app. None of that is visible to a developer who just launches Influxx and starts an agent session, which is exactly the point of doing the work.
"Ships on Three Platforms" Was the Commitment, Not the Easy Part
Influxx lets developers run and orchestrate more than thirty AI coding-agent CLIs side by side — Claude Code, Codex, Cursor, GitHub Copilot, Gemini, Grok, Droid, Amp, OpenCode, and others — each in its own isolated git worktree, with notes and agents living in one cockpit instead of a browser tab, a terminal window, and a notes app all fighting for your attention. macOS, Windows, and Linux were all stated targets from the first internal builds, not a line item to get to later.
That meant direct downloads on all three platforms, plus Homebrew on macOS, the Arch User Repository on Arch Linux, and AppImage, deb, and rpm packages for everyone else. It also meant accepting that "cross-platform" isn't a property of a build pipeline — it's a commitment to solve whatever problem each operating system independently hands you. Windows, Linux, and macOS don't share a packaging model, a process model, a display model, or a signing model. Committing to all three on day one meant absorbing all four of those differences at once.
Packaging Is Three Different Problems Wearing One Name
The first place the illusion of "one app, three platforms" breaks down is packaging, before any code even runs. Each OS defines a properly distributed desktop app differently, and none of those definitions share tooling:
- macOS wants a sealed, notarized artifact: we ship signed dmg and zip builds, both notarized so Gatekeeper doesn't greet users with an "unidentified developer" warning.
- Windows wants an installer with opinions: the packaged experience is an installer with its own custom uninstall process, because default uninstall behavior doesn't cleanly account for how Influxx's background pieces are laid out on disk.
- Linux wants no single answer at all: we ship an AppImage for portability plus separate deb and rpm packages, because Debian/Ubuntu-based and RPM-based distributions don't agree on much, including what to call the same underlying system dependency.
That last point is easy to underestimate until it bites you. A dependency that Debian and Ubuntu package under one name is often named completely differently on Fedora, openSUSE, or other RPM-based distributions, even though it's identical software underneath. We can't assume the two package definitions map onto each other — every dependency has to be checked and named explicitly for each packaging format, or installs quietly fail on exactly one of the two Linux package types while working fine on the other.
Windows: When Your Own Installer Becomes the Adversary
Windows produced more distinct engineering problems than the other two platforms combined — not because Windows is worse, but because it shares fewer assumptions with the Unix-rooted conventions most developer tooling is built around.
No Shebang, No Native CLI
On macOS and Linux, a command-line tool feels native almost for free. The shell reads the first line of an executable script, knows which interpreter to hand it to, and everything downstream — arguments, quoting, multi-line input — behaves the way Unix tooling has trained developers to expect for decades. Windows has no equivalent concept. There's no shebang line, and the command interpreter's quoting and escaping rules are different enough that you can't point the same binary at a command prompt and expect CLI-native behavior to fall out of it.
Making Influxx's CLI mode feel as natural on Windows as it does on macOS and Linux required a small, dedicated native launcher whose only job is relaunching the packaged app in CLI mode with arguments forwarded exactly as given. Our first pass at argument handling corrupted multi-line message content passed through the Windows command interpreter — newline and quoting behavior that Unix shells handle invisibly has to be handled explicitly on Windows, or it silently mangles anything more complex than a short, single-line argument.
"Unix shells hand you the shebang line for free — the OS reads the first line of the script and knows what to execute it with. Windows has no equivalent, so we couldn't just point at the same binary and expect it to behave like a CLI. We ended up writing a small native program with exactly one job: relaunch the packaged app in CLI mode and forward the arguments exactly as given. The first version got the quoting wrong and mangled multi-line input; getting that fix right took longer than the rest of the feature combined."
— Tobias Lindqvist, Staff Engineer, Platform at ETAPX
Signing Twice: A Pipeline Shape Notarization Doesn't Have
Windows code signing adds a wrinkle that has nothing to do with terminals and everything to do with how the signing provider itself works: it can't sign binaries that are already bundled inside a Windows installer. That forces a specific build order — sign the raw executables and libraries first, build the installer from those already-signed files, and only then sign the finished installer itself as a separate second pass. That's a fundamentally different shape from macOS notarization, where you build the artifact and submit it for notarization as one downstream step. Get the order wrong and you either ship unsigned inner binaries inside a signed shell, which defeats the purpose, or the build fails outright because the signing provider refuses to touch anything already sitting inside an installer.
The Update That Would Have Killed Your Session
This is the one that surprised us most, because it isn't a packaging quirk — it's a direct conflict between how Windows updates installed software and what Influxx is actually for. Influxx's value depends on long-running terminal sessions staying alive: an agent working through a large refactor overnight, a background session you check on the next morning. A typical Windows installer updates itself by force-closing every process running out of the install directory and deleting that directory outright before writing the new version.
On most desktop software that's a non-event, because most desktop software doesn't have anything important running in the background between launches. For Influxx it's a direct hit: it would kill every live agent session and every terminal attached to it, mid-update, with no warning. That failure mode barely exists on macOS or Linux, where update mechanics don't assume they can freely delete your entire install directory out from under running processes. The fix was to stop keeping the persistent background process that keeps terminals alive inside the install directory at all — we relocate it to a separate, versioned location that the installer's update routine never touches.
"I had a long agent session going against a data migration overnight on my Windows desktop, and Windows quietly installed an update in the background while I was asleep. I half expected to find the terminal gone and the session dead when I woke up. It was still there, still running, like nothing had happened."
— Renata Silva, infrastructure engineer and Influxx user
Linux: Assumptions a GUI App Isn't Supposed to Question
Linux's distinctive problems have nothing to do with packaging or updates — they're about a resource every GUI app assumes it has, and Linux doesn't guarantee: a display.
The Server With No Screen
Influxx, like any Chromium-based desktop app, assumes there's a display platform to render against. On macOS and Windows that assumption is safe; the OS always provides one. On Linux it isn't, and that gap matters for a specific, real use case: a developer who wants to park a long-running agent session on a remote box — a home server, a cloud instance, anything with no monitor attached — and check in later from somewhere else entirely. Without a real or virtual X server present, a Chromium-based app has nothing to fall back to; unlike a simpler headless service, you can't just disable the display subsystem and carry on. The fix is to detect when no display is present and automatically start a virtual display server in that situation, so Influxx comes up cleanly on a completely headless Linux machine without anyone having to configure a virtual display by hand first.
Wayland Gets Its Own Test Suite
Linux also gets a slice of automated testing that macOS and Windows don't need, specifically for Wayland — the display protocol steadily replacing X11 across current Linux distributions. Keyboard and terminal input behave differently enough under Wayland compared to X11 that we couldn't assume X11 test coverage would catch Wayland-specific regressions. Given that Influxx's entire interaction model runs through terminal sessions, input fidelity isn't a nice-to-have; it's the product, and that's worth a dedicated, separately maintained test suite rather than an assumption that one display protocol's behavior stands in for the other's.
macOS: The Smooth Path With Its Own Toll Booth
macOS is, in relative terms, the platform that surprised us least. There's no missing-shebang problem, no display-server assumption to defend against, and no conflict between updating the app and killing a running session the way there is on Windows. But smoother isn't free. Every build still has to be signed and notarized before Gatekeeper allows it to run on a machine we don't control, and that requirement is non-negotiable in the same way signing is non-negotiable on Windows — it's just handled in a single downstream pass instead of Windows' sign-then-package-then-sign-again sequence.
What "Cross-Platform From Day One" Actually Means
None of the work described above is visible to someone who downloads Influxx and starts using it normally. That invisibility isn't an accident — it's the actual deliverable. The alternative to doing this work is a product that quietly works better on whichever platform the engineering team happens to use day to day, and quietly disappoints everyone using a different one.
"People assume cross-platform means you write the app once and the packaging is a formality. In practice, every one of our three platforms sends you a different bill. Windows makes you fight your own installer. Linux makes you question whether a display even exists. macOS is kind by comparison, but it still wants everything signed and notarized before it'll let a stranger's Mac run it. None of that is a user-facing feature. It's just the cost of the commitment being real instead of aspirational."
— Tobias Lindqvist, Staff Engineer, Platform at ETAPX
Frequently Asked Questions
Does Influxx behave identically on macOS, Windows, and Linux?
The cockpit experience — the sidebar, the tab strip, running and orchestrating CLI agents in isolated git worktrees — is the same interaction model on all three. What differs is everything underneath: how the app is packaged and signed, how it updates itself, and how it handles a missing display. Those differences are built to be invisible from inside the app.
Why does Influxx need a separate native launcher program on Windows?
Because Windows has no equivalent to a Unix shebang line, so there's no built-in way to point at the packaged application and get native command-line behavior out of it — argument forwarding, quoting, and multi-line input all have to be handled explicitly. The launcher is a small native program whose only job is relaunching the app in CLI mode with arguments passed through correctly.
Will installing a Windows update kill my running agent sessions?
No. Earlier in development this was a real risk, because a typical Windows installer update force-closes and deletes everything in the install directory, which would have taken down live terminal sessions with it. We now keep the persistent background process that maintains terminal sessions in a separate, versioned location outside the installer's reach, specifically so an update can replace the application without touching sessions that are still running.
Can I run Influxx on a headless Linux server with no monitor attached?
Yes. Influxx detects when no display is present on Linux and automatically starts a virtual display server so the app can initialize normally. This is built specifically for developers who want to run a long-lived agent session on a remote box — a home server or a cloud instance with no monitor — and check in on it over SSH from another machine.
Why does Influxx ship three different Linux package formats instead of one?
Because Linux distributions don't converge on a single packaging standard the way macOS and Windows effectively do. We ship an AppImage for portability, native deb and rpm packages for Debian/Ubuntu-based and RPM-based distributions respectively, and an Arch User Repository package. Debian-based and RPM-based distributions frequently name the same underlying system dependency differently, so each package format has to declare its dependencies explicitly rather than assuming they line up.
Does Influxx support Wayland, or only X11?
Both, and Wayland gets its own dedicated automated test coverage rather than being assumed to work because X11 does. Keyboard and terminal input behave differently enough between the two display protocols that Influxx verifies Wayland behavior independently, which matters a great deal for an app whose core interaction surface is terminal sessions.
Three platforms, three genuinely different sets of constraints, and one product that isn't allowed to show the seams. That's the actual cost of writing "macOS, Windows, and Linux" on a download page instead of quietly favoring one and patching the other two into rough compatibility. Nothing in this piece ships as a feature anyone will notice — it ships as the absence of the failure modes described above, which was the point all along.
