Flows

A flow is a team of coding agents and the plan they follow, saved as a template. Pick one, give it an issue or a prompt, and cornercase starts the whole team in a new worktree: one tab per role, every agent with its model and its role prompt, and an orchestrator agent that runs the plan with the commands for scripts and agents, sending the work from the coder to the reviewers and back until it is done. The Flow panel draws the plan as boxes and arrows and lights it up as the work moves.

The Full issue flow on issue #482: the reviewer checks the fix again after one round of findings.

What a flow is

An orchestrator: an agent (Claude Code, Codex…) that reads what the others answer and decides what comes next. cornercase never parses a verdict out of an agent’s text: the orchestrator does, the way you would.
Roles: a name (coder, reviewer…), an agent, optionally a model and an effort, extra arguments and environment variables, whether it may edit files, whether it works in the run’s worktree or in one of its own, and its prompt. Each role gets a tab of its own.
Stages: the plan, in order. A stage holds one role, or several working in parallel (reviewer + security). A stage can send the work back to an earlier one when there are problems, at most a number of times (findings → 1 · at most 3).
The end: open a pull request, or leave the commits on the branch.
Notes: free text the orchestrator gets with its plan, such as do not change the public API without asking.

The built-in flows

Flow	Stages
Full issue	coder → reviewer + security (back to the coder on findings, at most 3 times) → tester (back to the coder on failures, at most twice) → a pull request
Cross review	coder → two reviewers (back to the coder on findings, at most 3 times) → a pull request
Quick	coder → reviewer (one round) → the commits
Bug, test first	a reproducer writes a failing test → coder → tester (back to the coder on failures, at most twice) → a pull request
Arena	two or three competing coders, each in a worktree of its own → a judge → an integrator → a reviewer (back to the integrator on findings, at most twice) → a pull request

They come with cornercase, so they improve with each update, and they use the agents you have installed: the default agent (settings → Agents → default agent) orchestrates and codes, and the reviewers take other agents when you have them, so a change is reviewed by a model that did not write it. You can change them: save a built-in flow from the editor and your version, kept in your folder under the same name, takes its place (tagged edited, and no longer updated with cornercase); restore default brings the built-in back, and delete hides one you never use (see Edit flows).

Unless a role asks for a worktree of its own, the whole team works in one worktree. Claude Code, Codex, Gemini CLI, Grok Build, Cursor CLI and GitHub Copilot CLI can take several roles of one flow; opencode takes one per worktree, since cornercase reads its status from its folder and cannot tell two opencode apart there: it can take several roles when they work apart. A flow that gives opencode two roles in one worktree says so in red and does not start, and the built-in flows give the other roles another agent. Two Codex or two Gemini CLI in one worktree still show their status, from their titles, but cornercase cannot tell their conversations apart: read --last-message fails for them, and the orchestrator reads their screens instead.

Start a flow

A flow works in a worktree of its own, so its project must be the root of a git repository. Start one:

From an issue: select it in the issue browser list, or open it, and click start a flow, after start and schedule (a narrow window drops it from the list, and the issue’s page keeps it). The prompt is the issue’s, made from your prompt template, and the branch is the one start would make (issue-482-…).
From the workspaces’ + New: start a flow…, for that project, with a prompt of your own. In the tree, each project’s own + New offers it too.
From the keys menu: w s.
From a script or another program: cornercase flow run NAME --issue KEY (a key such as #482 or ENG-42, or the issue’s URL) takes the task and the branch from the issue as start a flow does; --project ID says where when the issue isn’t tied to a repository and several projects are repositories. See Scripts and agents.

Starting Full issue on issue #482: the plan on the right, the issue's prompt and branch below.

The dialog lists the flows on the left under Flow templates, sorted by name, each with its number of agents and its description, or in red what keeps it from starting (a deleted built-in’s name is reserved), and draws the selected one’s diagram on the right (the wheel scrolls a diagram taller than its box). Below them go the prompt (what the team should do; Enter starts a new line, Tab moves to the branch), the branch, which follows the prompt’s first words until you type one (cornercase adds a short suffix when those words give nothing, a default branch or a branch already taken, so two runs of one task never share a branch; a branch you type is refused when it is main, master, the project’s default or the one its own folder is on). A project’s flow that sets environment variables or extra arguments for its roles says so in red, since they run without asking. Once you have accounts, an account list under the branch for each agent of the team that has accounts (claude account) chooses the account its roles start with (the one in use until you pick another); an account removed before you click start stops the start and says so. edit opens the selected flow on its edit page, as in settings → Flows, and brings you back; start starts it, shows the orchestrator’s tab and opens the Flow panel.

Starting a flow:

Makes the worktree, or uses a worktree already on that branch if it runs no flow, and one more for each role that works apart, on a branch made from the run’s. The project’s setup runs in each new one, with its own branch.
Opens one tab per role, named after it, the orchestrator first, each in its role’s worktree.
Starts each agent with its model, its effort, its arguments and its role prompt, which tells it to wait for the orchestrator’s first message, and answers its question about trusting the new folder. A role that may not edit the worktree’s files is told so in its prompt, and every role is told where to put its answers (see The run’s folder).
Starts the orchestrator last, once its team is up, with a brief cornercase writes: the task, the team with each role’s pane id, the stages in words, the flow’s notes, the rules for driving agents (wait before sending, one self-contained message at a time, read the last message rather than the screen, never answer another agent’s permission prompt), the run’s folder, the final action, and cornercase mark on its own pane when it is done, so the run shows as pending review.

The whole team starts at once, so the tabs and the diagram are complete from the first second; with the agents section on, the team hangs under its orchestrator there, each member listed by its role, and the team can be collapsed into the orchestrator’s row; an agent waiting for its first message costs nothing. The roles’ turns ending don’t notify you or leave a ✓ on their tabs, since the orchestrator reads them; the orchestrator does when the run is done, and any agent still does when it waits for you.

With the agents section on, a flow's team hangs under its orchestrator, each member by its role.

A run lives in its workspace: closing the workspace closes the run. It is saved with the session, so after a restart the agents resume their conversations in their tabs, each in its role’s mode, model and effort, and the orchestrator is told its team’s new pane ids.

The Flow panel

The panel draws the run of the workspace you are looking at. It opens by itself when you start a flow from the window; open it again with:

the workspace’s menu: right-click its row, or hover it and click ⋯, then show flow;
the keys menu: w f;
the Flow icon in the icon bar, shown while the workspace has a run.

It takes the column on the right that the changes, files and TODO panels share, so opening it closes the others. ×, Esc or w f again close it. Switch to a workspace without a run and the pane gets its width back; switch back and the diagram is there again. In the compact layout it covers the whole screen.

The plan, live: who works, where the work went last, how many rounds each loop took, and the files the roles wrote.

What it draws. The orchestrator sits on top, apart, since it moves the work. The stages go top to bottom, the roles of a parallel stage side by side (stacked under a bracket when the panel is too narrow), and each loop is an arrow up the right side into the stage it returns to, labelled with what sends the work back and its rounds (findings · 1/3). The end is ◆ open a pull request or ◆ leave the commits. Each box names its role in its own colour, then its agent, model and effort (claude · opus · high).

What lights up.

Each box shows its agent’s status, as the tabs do: ◐ working, ! waiting for you, ○ idle, and ✓ done for the orchestrator (a role’s finished turn shows as idle). A role whose tab was closed says closed.
A role that works gets a heavy border (┏━┓) in its colour.
The arrow the work last moved along takes the colour of the role it came from, and a ● travels along it for a second when a message goes through.
A loop counts its rounds, and turns orange past its limit.
When the orchestrator sends work somewhere the plan doesn’t go (skipping a stage, going back where no loop goes), the step it really took is drawn dashed on the left.
◆ turns blue once the run reaches its end: as soon as the run’s branch has a pull request on GitHub (open, a draft or merged; a closed one doesn’t count), or once the orchestrator has marked its own pane for review, its last step. The mark counts for the rest of the run, so the end stays blue while the orchestrator works on, waits for you or gets a follow-up; it is forgotten only if the run’s worktree moves to another branch. A flow that leaves the commits lights from the mark alone.
Next to the end, the pull request’s number coloured by its checks, as on the workspace’s row: #485✓ passed, #485• running, #485✗ failed, #486! merge conflicts, purple once merged, crossed out when closed. Click it to open the pull request dialog, where ask agent sends the failed checks to an agent. In a narrow panel the words are cut first and the number kept.

How it knows. From what really happens, not from what the agents say: every cornercase command run in a pane carries that pane’s id, so the orchestrator’s send, keys, read --last-message and wait are steps between real panes. A send into the next stage is that stage’s arrow; a send into the stage a loop goes back to is a round of that loop; anything else is outside the plan.

Clicks. Click a box to go to its tab. Click an arrow, or a loop’s label, to read the last message sent along it, with a copy button; where an arrow splits into a parallel stage, each branch shows the message its own role got. The arrows that carried a message light up under the mouse, a branch with the way it took. The wheel scrolls a diagram taller than the panel.

The messages are kept in memory only, at most the first 32 KiB of each: they never reach the log, which keeps their sizes, nor the saved session. After a restart the panel shows the plan and the agents’ status again, without the history; what the roles wrote to the run’s folder is still there.

The run’s folder

Every run gets a folder for its files, so long reports don’t pile up in the orchestrator’s context and the run leaves a record of what each role produced. It is outside the worktree, so nothing in it is ever committed, and every pane of the team has its path in $CORNERCASE_RUN_DIR.

One file per answer. Each role writes every answer to a file named after it and the next free number (reviewer-1.md, then reviewer-2.md) and replies with the file’s path and a few lines. The orchestrator passes work on by path instead of pasting text, and writes its own decisions there too (orchestrator-1.md: what it asked, what came back, what it decided and why). Scratch files, logs and scripts a role needs go there as well, never in the worktree.
Where it is. In runs/ next to the saved session (~/.local/state/cornercase/runs/ by default; with CORNERCASE_SOCKET, <session name>.runs/ next to the socket, so separate servers never share one), named by the day and the workspace (2026-10-17-fix-login, with -2 when taken). It and runs/ are readable only by you (mode 0700).
Who can reach it. Claude Code, Codex, Cursor CLI and GitHub Copilot CLI start with --add-dir for it, so their file tools can write there. Gemini CLI, opencode and Grok Build have no flag cornercase uses for it, and write through their shell, which the prompt tells them to do when their file tools can’t reach it.
The Flow panel lists it. Under the diagram, Files · n shows the folder’s files, newest first, with their age; click one to read it in the files panel. The list is read every two seconds while the panel shows, at most 200 files.
How long it stays. The folder survives the end of the run and a restart (a folder you deleted is made again), and goes with its workspace: removing the workspace (which removes its worktree), closing the project, or closing a plain workspace removes it, once the workspace’s shells have exited. cornercase close --workspace on a worktree, without --remove-worktree, only stops its shells: the workspace and the folder stay. cornercase flow run prints the folder on stderr, with run_dir in --json, and cornercase status --json gives each workspace’s run_dir, so a script finds the files of a run that ended.

A worktree of its own

By default every role works in the run’s worktree, so a reviewer sees what the coder wrote the moment it writes it. For work where several coders try the same task, set a role’s worktree to own (worktree = "own" in the file): cornercase makes it a worktree and a branch of its own, <run's branch>--<role> (fix-login--coder-a), made from the run’s branch, and its tab opens there. The built-in Arena flow does this for its competing coders; the diagram tags such a role’s box own worktree (own when the box is narrow).

Seeing the work. What a role has not committed is invisible to the rest, so the role’s prompt tells it to commit on its branch, and the orchestrator’s brief says to read a candidate with git log, git diff and git show on that branch, and to build or test it in its worktree folder. The role’s worktree is a row in the sidebar like any other, so you can open its Changes and Files panels to compare candidates.
Integrating. cornercase never merges a candidate. A role that works in the run’s worktree (the integrator in Arena) merges the chosen branch with git merge, or takes parts of the others by hand or with git cherry-pick; the orchestrator never edits.
Rules. Two roles that edit the run’s worktree in one parallel stage are a problem, and the flow does not start: give all but one a worktree of their own, or put them in stages of their own. Only a role can work apart, not the orchestrator, and two such roles cannot have names that make one branch. When a run starts on a new branch, its role branches must not exist yet; on a branch that exists, role branches and their worktrees already there are reused.
Lifetime and removal. The worktrees stay until the run’s workspace is removed, which asks first, checks every one of them for uncommitted changes, runs the project’s teardown in each and removes them all; the branches are kept. A role’s worktree cannot be removed on its own while its run lives.
A file needs version = 2 when a role has one; cornercase writes it that way and refuses a file that says own without it, so an older cornercase does not run the coders in one worktree.
Cost. Each worktree is a checkout and builds on its own, and the project’s setup runs in each, so several coders cost several times the disk and the first build.

Edit flows

Open settings → Flows, the tab right after Agents (Tab and ← → move to the other tabs, ↑ ↓ between flows), to list them, in one list sorted by name: a project’s flows are tagged this project, and built-in flows you changed edited. Click a flow to select it and see its diagram, and again (or edit) to open it. When the dialog is wide enough the diagram is drawn beside the list (the wheel over it scrolls a tall one); otherwise diagram shows it in place of the list and list brings the list back. A file that cannot be read says why instead of drawing a diagram. duplicate saves a copy in your folder and opens it, export and import share a flow, new starts a flow with a coder and a reviewer, and delete asks first. A built-in flow opens like the others: saving it keeps your version in your folder under the same name, in its place.

Deleting a built-in flow hides it, since it lives in cornercase itself and not in a file: it leaves Settings, the start dialog and cornercase flow list, and cornercase flow run refuses it and says how to bring it back. A built-in flow you edited offers both restore default, which deletes your file and brings the built-in back, and delete, which deletes your file and hides the built-in too. deleted built-ins, at the end of the list (click it, or Enter, to expand it), lists the ones you hid, muted with their diagram, and restore brings one back. A run already going keeps its flow. From a shell, cornercase flow hide NAME does the same as delete on a built-in flow, cornercase flow restore NAME as restore and restore default, and cornercase flow delete NAME deletes a flow of yours or the project’s (see Manage flows). A deleted built-in keeps its name: a project’s flow named like it is shown in red and does not run.

Settings › Flows: the flows sorted by name, with their agents and their plan, and the selected one's diagram beside them; Full issue has been edited.

A flow opens on its Flow tab, with a tab for the Orchestrator and one per role, and + add role to add one (at most eight). When the dialog is wide enough, the diagram is drawn beside the form as you change it; otherwise diagram shows it. The wheel scrolls it (↑ more and ↓ more at its edges), and the stage you are changing is drawn with heavy borders and scrolled into view.

Editing Full issue, with stage 2 open and drawn heavy in the diagram beside the form.

The Flow tab: the name, a description, where it is saved (yours, or the project’s), the stages, the final action and the notes. Click a stage to open it: roles (several work side by side), goes back (never, or to an earlier stage), when (what sends it back, such as findings) and at most (how many times). Hover a stage to move it with ↑ ↓ or remove it with ×; + add stage adds one.
A role’s tab: its name, agent, model (the agent’s default, the models cornercase knows for it, or other… to type one), effort (the agent’s default, or one of its levels: Claude Code low, medium, high, xhigh, max; Codex minimal to xhigh; Grok Build and GitHub Copilot CLI none, minimal, low, medium, high, xhigh, max; Gemini CLI, opencode and Cursor CLI have no effort switch; with Cursor it goes in the model id), args added to the agent’s command, env as KEY=value pairs (Claude Code on Bedrock, for example), whether it edits files, its worktree (shared, the run’s, or own, one of its own for competing coders and prototypes; not for the orchestrator), and its prompt. Renaming a role renames it in every stage.
Prompts and notes open a larger editor: Enter starts a new line, save keeps the text, cancel or Esc drops it.

save refuses while the flow has problems, listed in red under the form (a role in no stage, a loop that goes forward, an agent cornercase cannot start…). Renaming a flow renames its file. Closing a flow with unsaved changes asks first.

A flow is a file, so sharing one is sending text. Select a flow in settings → Flows and click export: its text is copied to your clipboard, even when cornercase runs on another machine, and the dialog says so. A teammate opens the same dialog and pastes (or clicks import and then pastes) on the Flows › import page, and import there opens the flow in the editor, not saved yet. Nothing is saved until they click save, so they can read what it does first; a name already taken becomes Quick 2.

The import page, with a flow pasted from a teammate.

Whoever imports a flow runs its env and args and its prompts, with every agent starting without asking for permission, so the editor shows what the flow sets in red, as it does for a project’s flow, and names the agents you do not have installed. The text is the flow’s own file under one comment line, the same TOML as the files below, at most 256 KiB: a bigger text is refused, on export and on import.

From a shell the same two steps are commands:

cornercase flow export Quick > quick.toml
cornercase flow import quick.toml
cornercase flow import quick.toml --to project --name 'Quick mine'

flow export prints the flow, and names on standard error any variable it sets, so you can check that no secret goes with it. flow import takes a file, - for standard input, an https:// address or OWNER/REPO of a community flow. It lists the roles, and when the flow sets variables or arguments, or comes from an address or a repository, it asks before saving (without a terminal, or reading - from standard input, it refuses unless you pass --yes). It saves in yours, or in the project’s .cornercase/flows/ with --to project. A name that is taken is refused: --replace overwrites that flow, and --name imports this one under another name. A built-in flow’s name can be taken with --replace, and yours then stands in its place; a name of yours or a built-in’s cannot be taken in the project’s flows, since they would never run. To share a flow with a whole team, commit its file to .cornercase/flows/ instead.

Community flows

usecornercase.dev/flows lists the built-in flows first, tagged built in (they already come with cornercase, so there is nothing to import), then flows that other people published in their own GitHub repositories, most starred first, with a search box. Each page shows the plan, the team and every prompt in full, and the file. To use one, import it from its repository:

cornercase flow import octocat/security-audit

OWNER/REPO is read from the repository’s default branch: flow.toml at its root, else cornercase-flow.toml. The command lists the roles, always asks before saving (without a terminal it refuses unless you pass --yes) and saves the flow in yours. In the dialog, type owner/repo or an https:// address on the Flows › import page and click import: cornercase fetches it and opens it in the editor, not saved yet, with a note that nobody reviewed it. An import is a copy that does not update itself; --replace brings in a newer one. A name that is also a folder or file on your disk is read as that path. To publish yours, see Publish a flow.

Trust and security

Nobody reviews community flows. Anyone can publish one, and the list is built by a script that skips a flow that is not valid, is longer than 256 KiB or sets env or args. That is all it checks.
A flow’s prompts drive agents that start in the mode that never asks for permission, so a prompt that tells an agent to run a command, read a file or send something runs it, on your machine. Read the page of a flow, every prompt of it, before you import it, and pass --yes only for one you have read. What a flow does is your responsibility.
An import is a copy: a repository changed or deleted later does not change yours, and the page shows the file as it was at the last refresh, so read the file you actually import.
The list leaves out flows that set env or args, but a flow you import from any address can; the import shows them in red.

Where flows are kept

Flows	Where
Built in	In cornercase itself. The ones you delete are listed by name in `hidden_flows` in `config.json`.
Yours	`flows/` next to `config.json`: `~/.config/cornercase/flows/`.
A project’s	`.cornercase/flows/` in its repository. Commit them to share a flow with your team.

Each flow is a TOML file named after it, so long prompts read well in a repository. A name is looked up in yours, then the built-in flows, then the project’s: a flow of yours with a built-in flow’s name replaces it, and a project’s flow, which comes with the repository you cloned, never stands in for yours or a built-in one, so give it a name of its own to run it. flow list and flow run say so when a name is in several places. A file cornercase cannot read is listed with its error, and can be deleted from the dialog.

name = "Quick review"
end = "commits"

[orchestrator]
agent = "claude"
model = "opus"
prompt = "Keep every message to an agent self-contained."

[[role]]
name = "coder"
agent = "codex"
model = "gpt-5.5"
effort = "high"
edits = true
prompt = """
Implement what the orchestrator asks, run the checks and commit locally.
"""

[[role]]
name = "reviewer"
agent = "claude"
prompt = "Review the changes on this branch. Do not edit files."

[[stage]]
roles = ["coder"]

[[stage]]
roles = ["reviewer"]

[stage.back]
to = 1
when = "findings"
at_most = 2

From scripts

cornercase flow list
cornercase flow run 'Full issue' --prompt-file issue.md --worktree fix-login
cornercase flow export Quick > quick.toml
cornercase flow import quick.toml
cornercase flow hide Quick

flow export and flow import share a flow. flow delete, flow hide and flow restore manage them, flow runs, flow messages and flow files follow a run, and a program with an editor of its own reads each flow whole in flow list --json and saves one with the flow-save request. flow list lists the flows with their agents and their problems. flow run starts one, answering once the tabs exist with the workspace’s id and each role’s pane id; nothing changes in the window unless you pass --focus. An agent can use them too, and start takes --model, --mode and --effort to start a single agent with a model, a mode and an effort of its own. See Start a flow in Scripts and agents.

cornercase status --json gives each workspace that runs a flow a run with its end and whether it was reached.

What is not covered

The files of a run that ended in the Flow panel, which shows only while a run does: cornercase flow files lists them, and run_dir is their folder. There is no way to turn the folder off; a flow’s own prompts can say not to use it.
Flows that span several projects.
A GitLab merge request at a flow’s end: the end reads GitHub pull requests through gh; elsewhere it lights from the orchestrator’s mark.
Scheduling a flow: the queue starts single agents.
Message events in cornercase events: a run’s messages are their own stream, cornercase flow messages.
Agents cornercase doesn’t know: a role runs Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI or GitHub Copilot CLI.