Agents

cornercase starts coding agents for you when you start an issue. An agent is just a command-line program that runs in a tab; cornercase knows the common ones, and you can add your own.

Known agents

Kind	Command	Built-in modes
claude	claude	yes
codex	codex	yes
gemini	gemini	yes
opencode	opencode	yes
grok	grok	yes
cursor	cursor-agent	yes
copilot	copilot
amp	amp
droid	droid
pi	pi
qwen	qwen
kimi	kimi
cline	cline
goose	goose
aider	aider

The kind is the name you use in settings and in config.json; the command is what cornercase types in the shell. The command must be installed and on your shell’s PATH.

Which agent takes an issue

When you press start, cornercase uses, in this order:

1. the agent you picked for this issue with agent…;
2. the default agent, agent in config.json (settings → Agents → default agent), unless it is auto;
3. with auto, the agent running in your current tab;
4. if there is none, it asks you to pick one.

cornercase106×21

How the running agent is recognised

cornercase looks at the program in the foreground of the active pane, and compares the file names of its first two arguments with each agent’s command. That way it recognises /usr/local/bin/claude --resume as claude, and also agents started through an interpreter, like node …/gemini-cli/bin/gemini, as gemini.

Codex’s npm wrapper, node …/@openai/codex/bin/codex.js, is recognised too. Its tabs show the model and context use from that pane’s own rollout file, following the wrapper’s native child, or by folder when Codex’s background app-server writes the rollouts. They also show whether Codex is working, needs you or finished, from OSC 7501 when emitted, otherwise the same rollout and Codex’s terminal title. The rollout format and the title are verified against Codex CLI 0.160.0.

What the agent is doing

Tabs where Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI or GitHub Copilot CLI runs show whether it is working, needs you or finished, and the rows above them show what needs you; see What your agents are doing. Under the tab’s name they also show the model and how full its context is. OSC 7501 reports take precedence for every recognised agent. Without them, cornercase recognises these seven agents in every pane this way, every half second. For Claude it reads the session file Claude Code keeps for that process in ~/.claude/sessions (or $CLAUDE_CONFIG_DIR/sessions) and the end of that session’s transcript in projects; for Codex, the terminal title Codex sets and the rollout file above; for opencode, the database it keeps its sessions in (~/.local/share/opencode/opencode.db), which has no pending permissions, so without OSC 7501 an opencode tab never shows !. Gemini uses its dynamic window title for status, and its session JSONL under <GEMINI_CLI_HOME or HOME>/.gemini/tmp/<project>/chats for prompts, replies and context. Keep ui.dynamicWindowTitle enabled and ui.hideWindowTitle disabled in Gemini’s settings for icons and notifications; a fixed or hidden title gives no status. Two Gemini using the same home in the same folder hide their conversation data. Grok Build is followed from $GROK_HOME (or ~/.grok): the row in active_sessions.json for the pane’s process, then that session’s events.jsonl, updates.jsonl, chat_history.jsonl, summary.json and signals.json. A permission prompt or an open question or plan approval shows !; other tools, including a shell, stay working. A prompt typed while it works waits. Its / and ! lines are local commands. Cursor CLI is followed from the chat store it holds open, <CURSOR_CONFIG_DIR or ~/.cursor>/chats/<hash of the folder>/<chat id>/store.db, which gives its model, context use, prompts and last message, and from the transcript under <CURSOR_DATA_DIR or ~/.cursor>/projects/<folder>/agent-transcripts/, which says whether a turn is open. Cursor’s terminal title only says what it is doing, and that it needs you, after /status-indicators is turned on in Cursor; without it a permission prompt shows as working, and ! never appears. The store format was read from Cursor CLI 2026.10.14’s code and has not been checked against a live session: a store cornercase cannot read shows no model, context or last message, never a wrong one. GitHub Copilot CLI is followed from $COPILOT_HOME (or ~/.copilot): the session-state/<id>/ folder whose inuse.<pid>.hold file the pane’s process holds open (a lock left by a process that died is ignored), that session’s events.jsonl for its model, context use, prompts and last message, and open-sessions-state.json for whether it is working. A permission prompt, a question it asks you and a plan awaiting approval show !; a background shell it started keeps it working after its turn, as for Claude Code; Ctrl+C or Esc ends the turn. Its / and ! lines and a lone ? are local commands. The model shows as auto until Copilot picks one. A resumed Copilot asks whether you trust the folder again unless you told it to remember it (--allow-all does not skip that question), and cornercase leaves the question to you. A Copilot started through npm (npm-loader.js) or gh copilot is recognised too (the tab of gh copilot is named gh), but those two paths have not been checked live, and neither has macOS. Other recognised agents get status icons and notifications when they emit OSC 7501.

For Claude Code, cornercase also reads the subagents it started in the background (the subagents/agent-<id>.jsonl files and their .meta.json beside the session’s transcript), and for GitHub Copilot CLI its subagent.started, subagent.completed and subagent.failed events: while some still run, the agent counts as working even when its own turn is over, and its second line says how many (see Subagents still running).

An agent started from another agent’s pane (with cornercase start, new-tab or split, or as a member of a flow) remembers that pane as its parent: the agents section lists it under its parent (a flow’s members by their role; click the ▾ before the parent’s icon to collapse them), and status gives the parent’s id and a member’s role (see Ids and where commands act).

Program Status Protocol

When a recognised agent emits OSC 7501, cornercase uses its reported state for the tab, the agents section, the working icon, desktop notifications and the Telegram or Discord messages while away. It works for agents in the catalogue and custom commands, even when cornercase has no session-file reader for them. No setting or hook is needed. Model, context and conversation resume still need an agent-specific reader.

Reported state	What cornercase shows
idle	Grey ○, ready for a new prompt. Cancelling work with this state does not mark it finished.
working	Yellow ◐, or the spinner you selected.
blocked	Orange !, waiting for permission, an answer or authentication.
done	Green ✓ while unseen, cleared when you open the tab.
error	Red !, failed, until another state replaces it or it is cleared. Scripts report failed.
clear	Remove the record and return to the existing detection when no records remain.

The agent writes a sequence to its terminal, for example:

printf '\033]7501;state=working\033\\'
printf '\033]7501;state=blocked:kind=permission\033\\'
printf '\033]7501;state=done\033\\'

cornercase110×44

BEL can end a sequence too. cornercase answers the protocol’s support query, OSC 7501 ; ?. Records can use hierarchical id values for subtasks: blocked takes priority over error, done, working and idle; clearing an id removes its children too. Reports persist without a heartbeat. A shell prompt expires idle, working and blocked records, and a full terminal reset clears all of them. A state from an old process never overrides a new agent in the same pane.

When no applicable report exists, the six readers above keep working as before. Invalid reports are ignored. A shell or build that emits the protocol is still a shell or build; the foreground command must be recognised as an agent.

Modes and arguments

Each agent starts with its command followed by its arguments, agent_args in config.json. To make the common choices easy, some agents have modes: named sets of arguments you pick from a list in settings → Agents.

Agent	Mode	Arguments
claude	accept edits	--permission-mode acceptEdits
	auto	--permission-mode auto
	plan	--permission-mode plan
	skip permissions (dangerous)	--dangerously-skip-permissions
codex	read only	--sandbox read-only
	workspace write	--sandbox workspace-write
	no sandbox, no approvals (dangerous)	--dangerously-bypass-approvals-and-sandbox
gemini	auto edit	--approval-mode auto_edit
	plan	--approval-mode plan
	yolo (dangerous)	--yolo
opencode	plan	--agent plan
	auto (dangerous)	--auto
grok	accept edits	--permission-mode acceptEdits
	auto	--permission-mode auto
	always approve (dangerous)	--always-approve

cornercase106×11

Every agent also has a default mode, which adds no arguments. Modes whose name contains dangerous are shown in red, in settings and in the issue browser, so you never pick one by accident.

Whatever is in agent_args beyond the mode’s arguments is the agent’s extra arguments, set with extra arguments… in the same list. When you pick another mode, cornercase swaps the mode’s arguments and keeps your extras. For example:

"agent_args": {
  "claude": ["--permission-mode", "plan", "--add-dir", "../shared"]
}

starts claude --permission-mode plan --add-dir ../shared: mode plan, extra arguments --add-dir ../shared.

Your own modes

agent_modes adds modes, replaces built-in ones with the same name, or hides them with an empty list:

"agent_modes": {
  "claude": {
    "plan": ["--permission-mode", "plan", "--verbose"],
    "auto": []
  },
  "mine": {
    "fast": ["--fast"],
    "careful": ["--careful", "--run-tests"]
  }
}

Here Claude Code’s plan mode gets an extra flag and its auto mode disappears from the list, while mine, a custom agent (see below), gets two modes of its own. Any agent can have modes this way, not only the ones with built-in ones.

Your own agents

agent_commands changes the program behind a kind, or adds a new kind:

"agent_commands": {
  "cursor": "/opt/cursor/bin/cursor-agent",
  "mine": "~/bin/my-agent"
}

The value is a single program, a name on your PATH or a path; put its arguments in agent_args. A new kind like mine shows up everywhere agents are listed, can be your default agent, and is recognised when it runs in a tab.

How cornercase starts an agent

Starting an agent is done by driving the shell in a new tab, the same way you would by hand. Each step waits for the terminal to settle before going on:

Step	Waits until	Then
1. Shell	The shell’s output has been quiet for 0.3 s (at most 5 s).	Types the command line and Enter.
2. Agent	The agent is in the foreground, has drawn something besides the command line, and its screen has been quiet for 1 s (at most 30 s).	If it asks whether you trust the folder, waits for your answer (or answers it, when trust prompts is on) and waits again; otherwise pastes the prompt.
3. Send	The screen has been quiet for 0.3 s after pasting.	Presses Enter, only when send the prompt is on.

If the shell is still in the foreground 3 s after the command was typed, the agent didn’t start (for example, the command doesn’t exist), and cornercase stops there. The reason goes to the server log.

The prompt is pasted with bracketed paste when the agent supports it. When the prompt is left for you to send, or the agent doesn’t support bracketed paste, it is put on a single line first.

Resuming after a restart

When a new server restores your session, a pane where Claude Code, Codex, Gemini CLI, Grok Build, Cursor CLI or GitHub Copilot CLI was running types the agent’s resume command into its new shell, once the shell has been quiet for 0.3 s:

Agent	Command typed
Claude Code	claude <arguments> --resume <session id>
Codex	codex resume <arguments> <session id>
Gemini CLI	gemini <arguments> --resume <session id>
Grok Build	grok <arguments> --resume <session id>
Cursor CLI	cursor-agent <arguments> --resume <chat id>
GitHub Copilot CLI	copilot <arguments> --resume=<session id>

The command and the extra arguments are the ones in settings → Agents; the mode is the one the agent was running in, found in its command line, so an agent started in plan mode comes back in plan mode even if another mode is set now. The session id is the one Claude Code writes to sessions/<pid>.json under ~/.claude (or $CLAUDE_CONFIG_DIR), the one in the name of the rollout file Codex keeps open, Gemini’s sessionId in its main session JSONL, Grok Build’s info.id in summary.json, or the chat id Cursor CLI names its chat folder with. A Cursor chat resumes only from the folder it was started in. A conversation with nothing in it yet isn’t resumed. An agent comes back under the same parent it had, which gets a new id like every pane. Turn it off with resume conversations (resume_agents). See Agents resume their conversations.

Keep the computer awake

An agent left working stops when the computer goes to sleep: its process freezes and its request or build times out. Turn on settings → Agents → keep awake (keep_awake) and, while at least one agent is working, the computer does not go to sleep on its own. Once none is, cornercase waits 30 seconds, so agents that end and start turns back to back don’t take and release it every few seconds, then lets the computer sleep as usual.

• What counts: an agent whose status is working, the ◐ on its tab (or the spinner, with working icon set to spinner). One waiting for you (!) does not, nor a Claude Code agent whose turn is over while a shell it started in the background still runs, so a dev server an agent left running doesn’t keep the machine up all night. Without OSC 7501, opencode never says it is waiting for you, so one at a permission prompt counts as working until you answer.
• Claude Code on a Mac already keeps the computer awake while it works, by itself. Grok Build can do the same with its own setting. Neither changes this one: cornercase still keeps one lock for every agent, and waiting for you does not hold it. The setting matters most for Codex, opencode and Gemini CLI, and on Linux.
• What it blocks: only sleeping when idle. The display still turns off, the screen still locks, and sleep you ask for (the menu, closing the lid) still happens.
• Which machine: the server’s, where the agents run. With cornercase remote the other machine stays awake; the laptop showing the window may still sleep, and the window reconnects when it wakes.

cornercase uses the system’s own tool, and stops it to let the computer sleep again; if the server stops, even killed, the tool stops with it:

System	Tool
macOS	caffeinate -i, shown in pmset -g assertions. It works on battery too.
Linux in a GNOME session	gnome-session-inhibit --inhibit suspend, since GNOME decides when to suspend from its own inhibitors.
Other Linux	systemd-inhibit --what=sleep:idle; over SSH, where systemd refuses to block sleep, --what=idle, which still holds back a server’s own idle action.

The row’s note says whether the computer is being kept awake now, by which tool, or why it can’t be on this machine (no tool, or the system refused). cornercase status --json has the same as keep_awake (held, by, unavailable) while the setting is on, and server.log says when it is taken and released.

Trust prompts

Many agents ask whether you trust a folder the first time they run in it, and a new worktree is always a new folder. Saying yes lets the agent use the repository’s own agent configuration, such as project settings, hooks and MCP servers.

By default the question is left to you. cornercase recognises it and waits: the prompt is pasted only once you have answered and the agent’s screen is quiet again. If you answer no, the agent exits and nothing is typed.

It recognises the question with trust_prompt_pattern, a regular expression matched without regard to case against the last 15 non-blank lines of the agent’s screen, where agents draw it. The default matches phrases like trust the files, trust this folder, do you trust and yes, proceed. An invalid pattern never matches.

With trust prompts on (accept_trust_prompts), cornercase answers yes for you:

• If the screen shows a menu, marked with ❯, ›, >, ▸ or →, and the marked option isn’t the yes one, cornercase moves the selection to the nearest option containing the word yes with the arrow keys, then presses Enter. Some agents highlight No by default, which is why.
• It answers at most four times per launch, and never the same screen twice.

Caution

A trust prompt protects you from running a repository’s agent configuration before you have looked at it. With trust prompts on, a repository with hostile agent settings runs them as soon as you start an issue in it, without you seeing the question. Turn it on only if you trust every repository you start agents in.