Termexo

Your answer to Omri is the most interesting thing on this page and nobody has followed it.Files already written remain on disk, and the in flight operation does not survive. So after a crash the filesystem has moved but the agent's belief about what it did is gone. On resume it reads a conversation that stops mid action, and nothing in that transcript tells it whether the tool actually completed. It cannot separate "the tool ran and I never saw the result" from "the tool never ran". If the action was idempotent that is harmless. If it was a migration, a push, a POST or an append, then redoing it and skipping it are both wrong and it has no basis to choose between them.The useful part is that Termexo is the only component that knows a crash happened. The CLI does not, because from its side a resume looks like a resume.Which means the fix is not process checkpointing, it is a note. On a resume that follows an abnormal exit, inject something the agent will read: this session was interrupted at 14:32 partway through an operation, verify state before continuing. That turns a confident silent continuation into a cautious one and it costs you one string.At the moment a clean resume and a resume after the machine died look identical to the agent, and those are the two cases that most need to look different.Asking as someone who runs agents on Windows daily: does the app currently know the difference between being closed properly and being killed?

The "notified when an agent needs approval" bit is the killer feature — babysitting permission prompts across parallel sessions is exactly what breaks the multi-agent workflow right now. How are you detecting the approval state, hooking into the agent's own permission protocol or parsing the PTY output? And does session resume survive a full machine reboot or just app restarts?

Storing API keys in Credential Manager is the right call. One thing I would want to know: does each model profile get its own isolated key, or is it one key shared across all agent sessions at once? Running a client project next to a personal one, I would want those credentials fully separated at the profile level.

finally something that treats windows like a first class citizen for agent workflows. the grid layout for multiple ptys is honestly the part that sold me, way easier to keep track of what each agent is doing

the recoverable part is what caught my eye more than the grid layout. when you say it resumes native sessions, does that survive an actual Windows update reboot or a crash, where the PTY process itself is gone, or is it more like restoring the pane arrangement and scrollback while the underlying agent process has to be kicked off fresh? that distinction matters a lot if you're mid-task on something long running.

the approval notification thing is honestly such a thoughtful touch, like that's exactly the kind of thing where you're away from your machine and an agent is just sitting there waiting on you. nice execution.

Alerting when an agent needs attention is the right primitive. The one nobody builds is the opposite alert, for the agent that's quietly burning your tokens on a loop going nowhere. The profiles already hold the API key, so you could put spend per session next to each PTY tab, and that number changes behaviour faster than any layout feature will. Running two agents at once and having no idea which one ate the budget is the part that actually costs me.

Windows-native is the underserved half of this space — most of the agent tooling assumes macOS, and the WSL workaround means your agent and your editor disagree about what a path is.Does it run the agent inside WSL, on native Windows, or does it let you pick? I ask because the path translation is where I'd expect the friction to actually live. An agent that writes /home/user/... into a config a Windows tool has to read is the kind of thing that works in the demo and breaks in week two.

Storing API keys in Windows Credential Manager instead of a config file is the kind of detail that gets this trusted fast.

Hi Product Hunt! I built Termexo after my own terminal setup became harder to manage than the coding tasks themselves.

I often run Claude Code and Codex side by side across several projects. One agent is working, another is waiting for approval, and yesterday's useful session is buried under a different path or branch. Termexo brings those native CLI workflows into one local Windows workspace.

It keeps agents in real PTY terminals, restores workspace layouts, searches and resumes native sessions, alerts you when an agent needs attention, and supports Claude-compatible model profiles with API keys stored in Windows Credential Manager.

Termexo is Windows-only today, does not require a Termexo account, and is still evolving. I'd especially value feedback from people who run multiple coding agents at once: what part of that workflow wastes the most time for you?

— 爱玩科技