infomarchy

The public preview is the real plugin rendered on an empty Omarchy desktop using Infomarchy's explicit, transient demo-data mode. It contains no live prompt, hostname, username, network, path, process, or session data.

Want to see the plain desktop? After configuring the shortcuts, press SUPER + I to hide the Infomarchy cards and reveal your wallpaper. Press SUPER + I again to bring the dashboard back.

Why

You run Claude Code in three terminals, Codex in a fourth, Grok is poking at a repo somewhere, Ollama is warming a model, and your weekly limit is quietly at 86%. The only way to know any of that is to go look — tab through windows, read titles, run nvidia-smi, open a dashboard.

Infomarchy puts all of it on the one surface you always have open and never use: the wallpaper. It's not a widget in the bar and not another window to manage. It's the desk itself, and it's always current.

What you get

🟡 Live AI sessions — who is working right now

One card per running agent — Claude Code, Codex, Cursor, Grok, Grok Bot, Gemini, Hermes, opencode, aider, Ollama chats — detected straight from /proc, no agent-side hooks, nothing to configure. Each card shows the project, working directory, how long it's been up, the pid, the workspace it lives on, and the terminal's own title. Its two-line current topic is a short synopsis derived from several exact-session requests—not the last prompt copied onto the card. A loaded local Ollama model may refine the wording; summaries are cached by session/content and Infomarchy never auto-loads a model. The dot pulses while the agent is thinking.

Zombies. A session nobody is attached to (background, or no window and nothing to attach to) that is not busy and has had no prompt for six hours gets a STALE · idle Nh tag on its card. Right-click it: a background Claude session offers STOP SESSION (claude stop <id> — graceful, the conversation stays resumable), anything else stale offers END PROCESS (SIGTERM, only after the helper re-verifies the pid still belongs to the process the card described). Both need a second confirming click within four seconds; nothing is ever stopped automatically. Claude Code's own registry (claude agents --json, consulted only when its daemon is already running) supplies exact session ids, display names and live busy/blocked state for every running Claude, and marks background sessions — the ones started with --bg or living under the daemon — whose cards open a terminal attached to the running session (claude attach <id>). Agents hosted inside Herdr, Boomux, or tmux remain visible. Their large session card reports the host and its bounded identity: Herdr workspace/tab/pane, Boomux workspace/shell plus exact shell/run IDs in the snapshot, or tmux session:window.pane. Infomarchy reads only those documented identity variables from the agent environment; unrelated environment values are never serialized. An attached tmux pane is matched to its client terminal, and a Herdr-hosted agent to the terminal running the Herdr client (the agent descends from herdr server, a daemon, so plain process ancestry never reaches the window). Clicking the card focuses that terminal and then jumps inside the multiplexer: tmux select-window / select-pane / switch-client for tmux, workspace.focus / tab.focus / pane.focus over Herdr's socket API for Herdr (its CLI only exposes a directional pane focus), via the bundled herdr-focus.ts, each id validated and the socket taken from the agent's own environment. For Boomux the window is matched through the boomux __attach <shell-id> client process, or the terminal title Boomux sets (boomux:shell:<node>:<shell-id> | workspace - name); the jump focuses that window and runs boomux open <shell-id> --workspace <workspace-name>, which shows the Workspace layer and re-focuses the existing terminal (verified against Boomux 1.9.7: no duplicate window; a bare open neither moves focus nor duplicates). A shell created from inside Herdr inherits Herdr's variables, so Boomux is resolved first and the inherited Herdr host is dropped. A host with no client window at all shows no client window found rather than guessing one. Remote-only processes on another machine are outside local /proc and are not fabricated.

Cursor. Both ways of running it get a card. cursor-agent in a terminal is an ordinary session. The IDE is the interesting one: when the conversation lives in Cursor rather than a terminal, the process that actually runs the agent is cursor-agent worker — one per open workspace, each bound to a single directory with its own pid, cwd and counters. It reads like a service and is not one, so it is not excluded the way Codex's app-server is; excluding it would leave a machine driving Cursor entirely from the IDE, which is most of them, with no Cursor session at all. Those cards are marked background and dimmed like Claude's --bg sessions, because you drive them from the window and not a terminal, and clicking one focuses Cursor. The genuine one-shot management commands (login, update, mcp, models, plugin, …) are excluded. The subcommand is matched across the whole argument list rather than at argv[1], because the IDE puts it after several flags.

A worker lives as long as its Cursor window, not as long as a conversation — so unlike a terminal agent you close when you are done, a Cursor card can sit on the desk for days. That is why the STALE tag and quiet grouping matter more here than for anything else; liveness is the process, and decay is the last prompt.

History comes from Cursor's own transcripts at ~/.cursor/projects/<dashed-cwd>/agent-transcripts/<chatId>/<chatId>.jsonl, in the same role/message shape Claude Code writes; CURSOR_HOME overrides the root. Two quirks are handled rather than guessed at. The directory name is the working directory with every / replaced by -, which is ambiguous as soon as a path segment contains a dash of its own, so it is resolved against the filesystem — home-you-repos-four-monorepo becomes ~/repos/four-monorepo, not ~/repos/four/monorepo — and an unresolvable name yields no project rather than a fabricated path. And there is no timestamp field: the only clock is a <timestamp> tag the client injects into each user turn, parsed explicitly because Date.parse reads that string inconsistently and drops the offset on some builds, with the file's modification time as the fallback.

Which chat a worker is on comes from the newest transcript under its own directory. That has to be read rather than inferred: the generic inference only accepts a prompt within half an hour of launch, which fits a terminal agent prompted right after starting and not a worker that outlives any one conversation.

Cursor is also the one provider with a real busy signal instead of a terminal-title guess: a transcript ends with {"type":"turn_ended"} once the agent has finished, so a trailing assistant turn without it means it is still working. For a worker the title could not have helped anyway — it belongs to the IDE window, which is shared by every workspace. Known limitations: Cursor's hooks and rules inject their own turns as role: "user", wrapped in <user_query>, timestamped, and positioned exactly where a typed prompt goes — there is no field that separates them, so they appear in RECENT TASKS alongside what you actually asked, and filtering them would mean a content heuristic that could drop real prompts. All of a machine's workers also share the one Cursor window, so clicking any of their cards focuses Cursor but cannot switch it to that workspace. And Cursor publishes no local token or quota data, so it contributes no USAGE row.

Grok Bot. The xAI desktop app runs every bot in its roster inside one Electron process, so /proc shows a single agent no matter how many bots you have. Infomarchy reads the app's own local roster — ~/.config/Grok Bot/sand-client-persistence, one plain-JSON file per state slice, each named by the base32 of its key — and gives each bot its own card: its name, the last line it wrote (markdown flattened, secrets redacted like any other prompt), and whether it is waiting on your answer or holding replies you have not read. Bots you hid from the sidebar get no card, and transcripts are never opened. Since the bots share one process, its CPU/RAM/GPU counters are attributed once, to the bot the app currently has open; the other cards show — rather than repeating the same process on every card. Clicking any of them focuses the Grok Bo