Agents

What each agent can do

Argus does not care what runs in a session: if it runs in a terminal, it works — you see it, type into it, hand it prompts and read the files it writes. That part has no matrix.

What does differ is the handful of things where the agent has to meet Argus halfway: it has to tell us something no amount of watching from outside can work out. There are two, and this is who can do them.

	Claude Code	Codex	Gemini CLI	a shell
Terminal, files, documents, prompts	yes	yes	yes	yes
Prompts, with the Enter pressed for you	yes	yes	yes	yes
Two agents on one job	yes	yes	yes	—
Rings when it finishes or wants you	yes — Stop and Notification hooks	yes — notify, at the end of a turn	no — nothing to hook	no
Says which folder it is in	yes — the status line hook	no	no	not needed
Folder shown with nothing wired	where it started	where it started	where it started	where it is, live

Both of the bold rows are switches in Settings, and both write into the agent's own configuration file: Let your agents ring and Let your agents say where they are. They keep a copy of the file as it was before Argus first touched it, they report a hook you wrote yourself rather than replacing it, and turning them off takes back only what carries Argus's own marker.

Why the ring cannot be automatic for Gemini

Because there is nothing to wire. ~/.gemini/settings.json holds an auth type and a theme, and the CLI's own help offers no hook, no notify and no status line. Checked, rather than assumed — and it will change the day Gemini grows one, which is when this table changes too.

Gemini sessions are otherwise ordinary sessions: the bell is the only thing missing, and you can still be told by watching, which is what everybody did before the button existed.

Why "says which folder it is in" is only Claude Code

An agent never chdir()s its own process. It runs your commands in children, and keeps its own idea of where it is working — so tmux, /proc and everything built on them go on naming the folder the session was started in, however far the work has moved. Measured: a claude working elsewhere still reported its start directory from both pane_current_path and /proc/<pid>/cwd.

The only cure is the agent saying so, and Claude Code has the place to say it: its status line hook is handed workspace.current_dir on every turn, and the script Argus installs writes that into a tmux pane option that Argus prefers over anything it can observe. Three options, in fact, and each is a thing nothing outside the agent can work out:

@argus_cwd	the folder it considers current
@argus_model	the model it is running — the process is called claude whatever is behind it, and a model named in a config is the one it started with
@argus_agent	its own name, which matters on a board: a tile has no process tree to read and no business running ps on somebody else's machine

Anything can write them — tmux set -p @argus_cwd /the/folder — so a wrapper script or a shell prompt can do for another agent what the hook does for Claude Code.

They reach a board too. Panoptes shows the agent's name on the session chip and the model in its tooltip, taken from what the session declared and never inferred: what a session says is what a tile shows, and one that says nothing shows nothing.

Codex has no equivalent, so its window shows where it started and says "started in" rather than pretending. See Sessions and the terminal.

What none of them need

Nothing is installed inside the agent for the ordinary work: no plugin, no MCP server, no wrapper. The two switches above are hooks in a config file you can read, and the two-agent patterns are a markdown file both agents can open. That is the whole integration surface, on purpose — it is why an agent that changes next month does not take Argus with it.