Guide

Run OpenCode in the background, as an always-on-top overlay

Run OpenCode in the background, as an always-on-top overlay

To run OpenCode in the background, lean on the design it already has: OpenCode runs a backend server, and the TUI you look at is just one client of it. The agent keeps reading files, running commands, and editing code even when its window isn't focused. The missing piece is a calm way to keep an eye on it — and that's an OpenCode overlay: a thin, always-on-top window that floats over your editor, your browser, or a borderless-fullscreen game and surfaces the agent's state without an alt-tab. This guide covers both halves: the docked-panel approach OpenCode gives you out of the box, and floating it as a true overlay so it sits over everything.

One honest framing up front, because it shapes everything below: Backgrind is the overlay around OpenCode, not OpenCode itself. OpenCode is the agent; Backgrind is the always-on-top surface and the notification layer in front of it. If you're new to the agent, start with what is OpenCode or how to install OpenCode first, then come back here for the overlay part.

Why you want OpenCode in the background

An agent changed how long a single command takes. You describe a task, hit enter, and OpenCode spends the next several minutes greping, editing, and running tests on its own. You've already moved on — to your editor, a PR review, docs, or a game churning in another window. But the agent isn't truly fire-and-forget: every so often it stops to ask permission, asks a clarifying question, or finishes and waits. If its window is buried under three others, you find out late, and the agent sat idle while you were heads-down somewhere else.

"In the background" is exactly the right instinct, but it has a failure mode: background usually means blind. You stop watching, so you miss the one second the agent needed you. The fix isn't to babysit the terminal again — it's to make the background state glanceable, and to get a nudge on the moments that matter. That's the whole reason to put OpenCode behind an overlay instead of leaving it in a tab you have to remember to check. The same logic applies to any terminal agent, which is why people run Claude Code in the background the same way.

Docked panel vs a floating window

There are two shapes for "OpenCode on top," and they solve different problems.

The docked panel is the cheap version, and it's the one OpenCode's own design hands you. Because the agent is a server and the TUI is a client, you can keep a terminal pane open in a tiled layout — a split in your editor, a tmux pane, a column in your window manager — and the agent's output stays in view while you work in the other half of the screen. It's reliable and costs nothing extra. The catch is that it only works inside your desktop chrome: the moment you go borderless-fullscreen in a game or a full-screen app, the docked panel is gone, hidden behind whatever took over the screen.

The floating always-on-top window goes further. Instead of living in your tab order, it sits at a higher window level than everything else, so it stays visible over a maximized editor, a browser full of docs, or a borderless game. This is the OpenCode always-on-top behavior people actually want when they say "overlay" — not a pane in the layout, but a layer above the layout. A good overlay adds click-through ("ghost") mode so the floating window passes your clicks and keystrokes to whatever is underneath; the terminal is visible but inert until you flip it interactive to answer. If you've ever rigged a generic window pinner for this, our piece on the always-on-top terminal over any app covers why a plain pin isn't enough.

Float it over fullscreen

The overlay's headline trick is sitting over a game while a long task grinds. There's an important constraint to state plainly, because it's a hard limit, not a roadmap promise: the overlay works over borderless-fullscreen only. A borderless-fullscreen window is still a normal window the compositor can stack things on top of, so an always-on-top layer can float above it. Exclusive-fullscreen (where the game takes the whole GPU output) is a different mode the overlay can't sit over, and there is no render injection in v1 — the overlay is a plain top-level window, not something drawn inside the game. Most titles either default to borderless or offer it in the display settings, so in practice this covers the common case; it's just worth knowing the line.

Two more hard rules, because they're the difference between a legitimate tool and a bannable cheat. There is no game-memory reading and no in-game input automation. The overlay renders a terminal and forwards your keystrokes to OpenCode; it never touches the game's memory and never sends synthetic input into it. It's a window that happens to float on top — nothing about it interacts with the game itself. We go deeper on why that matters in will a coding overlay get me banned, and the same pattern is what makes it safe to run Claude Code while gaming.

Ambient notifications instead of babysitting

A floating window you can see is necessary but not sufficient. Visible doesn't mean noticed — you're focused on the game or the editor, not staring at a terminal in the corner. The real upgrade is that the overlay tells you, instead of you watching it.

Ambient notifications fire only on the moments that matter: when the agent finishes, or when it stops on a decision — a permission prompt or a clarifying question. The overlay stays quiet otherwise, so you're not buried in noise while it works. That inverts the babysitting problem: you can truly look away, and the one second the agent needs you becomes a flash-and-chime instead of a missed prompt and an idle agent. With several sessions open — one per repo — the tab that pinged gets an accent ring, so you know which agent wants you.

A point that matters for trust: the overlay is a dumb frontend. It renders the terminal and forwards input, and it does not store or transmit your conversation history. The agent's content stays between OpenCode and whichever model provider you connected — the overlay just needs to know "did the agent finish or stop?" to decide whether to flash. Nothing about going to the background routes your code through someone else's server. A background daemon keeps the agents alive even if you close the window, so a pinged decision still reaches you while the UI is hidden.

Drive it from your phone with Live mode

Floating over a game solves "see it." Live mode solves "I walked away from the desk." With Live mode the desktop app mints a pairing code, and a browser console — on your phone, a tablet, a laptop on the couch — attaches to the same OpenCode session over the network. You can read what the agent is doing and answer a prompt or type a follow-up from anywhere, then put the phone down and let it keep grinding.

This fits OpenCode cleanly because the agent already lives in a server that multiple clients can attach to; Live mode is just another client, reached through the browser. The desktop side stays in control: it initiates the pairing, so a session is never exposed without you starting it. Full walkthrough in control your coding agent from your phone.

Or run the hosted Grindy version

Everything above assumes you're running your own OpenCode with your own provider keys, in the overlay. If you'd rather skip the setup entirely, there's a hosted path: Grindy is OpenCode running server-side, managed by us, with a real Claude engine wired in behind the scenes — nothing to install and no provider key to manage. You pick the Grindy model in the overlay and the agent runs on our infra instead of your machine.

The overlay treats it the same as a local agent: float it over your editor or a borderless game, get the same ambient notifications on finish-or-decision, and drive it from your phone with Live mode. Grindy is the zero-setup option, not the only one — bring-your-own OpenCode is fully supported. The difference is just who runs the server and who manages the model. If you're weighing engines, see OpenCode vs Claude Code.

Frequently asked questions

How do I run OpenCode in the background?

OpenCode already runs a backend server that any client attaches to, so the agent keeps working even when no window is focused. To make that practical, put it behind an always-on-top overlay that floats over whatever you are doing and pings you only when the agent finishes or needs a decision — so "in the background" does not mean "blind."

Can I run OpenCode as an overlay over a fullscreen game?

Yes, over borderless-fullscreen apps. An always-on-top overlay window floats above a borderless game; it does not work over exclusive-fullscreen (which takes the whole GPU output), and there is no render injection in v1. There is no game-memory reading and no input automation either.

Is Backgrind the same thing as OpenCode?

No. OpenCode is the open-source coding agent. Backgrind is the overlay and notification layer around it — a thin, always-on-top window that runs your real OpenCode CLI and pings you on the events that matter. It does not store or transmit your conversation history.

Can I control OpenCode in the overlay from my phone?

Yes, with Live mode. The desktop app mints a pairing code, and a browser console on your phone attaches to the same session over the network, so you can answer a prompt or steer the agent away from your desk.

Where Backgrind fits

Backgrind is the overlay around OpenCode, not the agent itself: a transparent, always-on-top window that runs your real OpenCode CLI — your login, your history — with click-through, ambient notifications on finish-or-decision, and per-folder session tabs, plus Live mode to drive it from your phone. It's a dumb frontend by design: it renders and forwards, and never stores or transmits your conversation history. A background daemon keeps the agents alive even if you close the window, so running OpenCode in the background stops meaning running it blind. Prefer no setup? Grindy gives you a hosted OpenCode with a Claude engine and nothing to configure. Either way, you can feel the flash-and-chime loop in the live demo before installing anything.