Projects, workspaces and tabs

cornercase organises your shells in three levels, each in its own column: projects (folders) hold workspaces (lines of work), and workspaces hold tabs (shells, possibly split into panes). Everything is opened, switched, reordered, renamed and closed with the mouse.

feat/gift-cards hovered: a lighter background, and its ⋯ and × buttons.

Projects

A project is a folder. The projects column lists them, each with its number of workspaces in parentheses (turn them off in settings → UI → counts); a new one goes at the end, and you can drag them into any order. Click one to make it active; the second column then shows its workspaces.

A project is called after its folder (~ for your home folder) unless you rename it.

Open a project

Click + New at the end of the list, then open project. A folder picker opens in the folder that contains the active project, or in your home folder.

To	Do
Filter the list	Type. Exact names come first, then names that start with what you typed, then names that contain it.
Go into a folder	Click it, or select it and press `Enter`, `→` or `Tab`. Typing `/` also goes into the selected folder.
Go up	`←`, the `..` entry, or `Backspace` when the filter is empty.
Jump home or to `/`	Type `~` or `/` while the filter is empty. Pasting a path walks it the same way.
See hidden folders	Start the filter with a dot.
Open the folder you are in	Click open, or press `Enter` when nothing is selected.
Cancel	Click cancel or press `Esc`.

Folders that are git repositories show their current branch on the right. Opening a folder that is already a project switches to it instead of opening it twice. VS Code workspace files (.code-workspace) are listed after the folders, tagged vs code, also while you filter; choosing one imports it as a group.

Groups

When the projects column gets long, put projects in groups: work, personal, open source. A group is a header with an icon, a name and a colour, and its projects are listed below it, indented. Projects without a group stay at the top of the list, as before.

work is open and personal is collapsed.

To	Do
Create a group	Click `+ New`, then new group, and type its name. It gets its own icon and colour: the first eight groups each get a different one, starting with a blue `●`.
Add a project to a group	Click its header’s `⋯` or right-click it, then add project. The folder picker opens next to the group’s projects, and the folder you open goes straight into the group.
Put a project in a group	Click the project’s `⋯` or right-click it, choose move to group, then the group. no group takes it out again. You can also drag it onto the group’s header or between its projects.
Collapse or expand a group	Click its header. A collapsed group shows how many projects it holds, and gets the cyan `▌` when the active project is inside.
Rename a group	Click its `⋯` or right-click its header, then rename group.
Change its icon or colour	Click its `⋯` or right-click its header, then icon and colour.
Delete a group	Hover its header and click the `×` at its right end, or open its menu and choose delete group. cornercase asks first: keep projects leaves them open and ungrouped, close projects closes them too and stops their shells. An empty group only asks to confirm.

A new group goes at the end of the list; drag its header to move it. There is a single level: a group can’t hold another group. Scripts and other apps do the same with cornercase group, move, collapse and expand; see Scripts and agents.

Import a VS Code workspace

Coming from VS Code with one workspace per area of work? Open its .code-workspace file from the folder picker (+ New, then open project) and cornercase turns it into a group:

The group is named after the file: work.code-workspace becomes work. If a group with that name already exists, the folders go into it, so importing the file again brings in folders added since.
Each folder of the workspace opens as a project in the group. A folder with a name in the file gets that name, unless you already renamed that project in cornercase. Relative paths are read from where the file is, as VS Code does.
A folder that is already open moves into the group instead of opening twice. Folders that don’t exist, and remote ones, are skipped; a message says how many projects were imported and how many folders were not found. A folder whose shell can’t start (one you may not enter, for example) is skipped too and the rest still open; the message counts it, and server.log says which folder failed and why.

The import happens once: after that the group is cornercase’s, and the .code-workspace file is never changed. Comments and trailing commas in the file are fine.

Icon and colour

Open it from the group’s menu (its ⋯, or a right-click on its header), icon and colour. The dialog has twelve icons and sixteen colours. Every click applies at once, and the header at the bottom of the dialog shows the result; close it with done, Enter or Esc.

The icons are plain symbols that every font has at one cell wide, so they line up in any terminal. The colours are the terminal’s palette colours, so they follow your theme.

Workspaces

A workspace is one line of work inside a project. Every project starts with one: the project folder itself, called after its git branch (main), or default when the folder isn’t a git repository.

Click + New under the workspaces, then new workspace, to start another one (start a flow…, in the same menu, starts a flow: a team of agents in a workspace of its own). You give it a name and, when the project folder is the root of a git repository, choose whether it gets its own worktree:

With its own worktree (the default in a repository): the name is a branch, and the workspace is a separate checkout of the repository in ~/.cornercase/worktrees/<repo>/<branch>. Its files, builds and agents don’t touch your other work. See Git worktrees.
Without: the workspace uses the project folder itself, under the name you chose. This is handy to keep a group of tabs together, for example a servers workspace next to main.

A workspace is called after its custom name, otherwise its branch, otherwise default. When the checkout is on a detached HEAD, the short commit hash takes the place of the branch.

Worktrees of the repository that you create outside cornercase, with git worktree add, appear as workspaces by themselves, at the end of the list. A worktree you remove outside cornercase goes away once its tabs are closed, also when git forgot it but its folder is still there (after git worktree prune, or a removal that failed half way); that folder stays on disk for you to delete.

When a workspace’s branch is behind its upstream, its row ends with the number of commits to pull, such as ↓3. See Commits to pull. When the branch has a pull request on GitHub, the row shows its number, coloured by its checks, such as #485✗ when one failed, or #486! in orange when it has merge conflicts; click it to see its checks. See Pull requests and their checks.

Tabs

Each workspace lists its tabs under its name. Click ▾ beside a workspace’s name to collapse it and ▸ to expand it again: its tabs leave the list, but their shells and agents keep running, and a collapsed workspace shows one icon at the end of its row, the most urgent status of its agents (working and idle included). A click on the rest of the row opens the workspace and expands it. With tabs above the pane there is nothing to collapse.

feat/dark-mode is collapsed: its row shows what its agent is doing.

Click + Tab under a workspace to open a new shell in the workspace’s folder; the new tab goes at the end.

A tab is named after the program in the foreground of its pane, so the name follows what you do: bash while you are at the prompt, nvim while you edit, claude while an agent works. A split tab is named after its first pane, the top-left one, so the name stays put while you click between panes, and a grey +n at the end of its row says how many other panes it holds. A program run by an interpreter (Node, Bun, Deno, Python, Ruby) is named after its script file, so Codex or Gemini CLI installed with npm show as codex and gemini, not node. Without a script file, such as a bare Node prompt, python3 -m http.server or node -e '…', the tab keeps the interpreter’s name. A known agent is named after its kind, such as cursor for cursor-agent. Tabs started from an issue in a folder that isn’t a repository are named after the issue instead.

The shell is the one in your SHELL environment variable when the server started, or /bin/sh if it isn’t set.

What your agents are doing

An icon before the tab’s name tells you what a recognised agent is doing when it reports OSC 7501, or when a reader is available for Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI or GitHub Copilot CLI:

Icon	Means
`◐` yellow	The agent is working. With working icon set to spinner in settings → UI, it is a spinner instead, `⠋⠙⠹⠸⠼⠴⠦⠧⠇⠏`, turning about ten times a second. For Claude and GitHub Copilot CLI, also while it waits for a command it started in the background (a build, a test run); `cornercase status` tells scripts that case apart. Also while it waits for subagents it started.
`!` orange	The agent needs you: it asks for permission or asks you a question. Any recognised agent reporting OSC 7501; otherwise Claude Code, Codex, Gemini CLI, Grok Build, Cursor CLI and GitHub Copilot CLI (Cursor only with `/status-indicators` turned on; Copilot for a permission prompt, a question or a plan awaiting approval).
`!` red	The agent reported a failure through OSC 7501. It stays until the agent reports another state or clears it.
`●` blue	You marked the agent as pending review. It stays until you mark it as reviewed, send the agent a new prompt or answer its question; opening the tab does not take it off.
`✓` green	The agent finished while you were looking at another tab. It goes away when you open the tab, or when a program that draws cornercase shows it.
`○` grey	The agent waits for your next message.

So that a finished or waiting agent in another project doesn’t go unnoticed, !, ● and ✓ also show at the end of its workspace’s row (a collapsed workspace shows its most urgent status, ◐ and ○ too), of its project’s row and, while the group is collapsed, of its group’s header. When several tabs below a row disagree, orange ! wins over red !, then ●, then ✓. In the compact layout the ≡ button shows them for every tab except the one on screen. To see every agent at once and jump to the one that needs you, turn on the agents section.

Pending review

When several agents finish at once, you rarely review them all straight away. Right-click a tab running an agent (or click its ⋯), its row in the agents section, or inside the agent’s pane, and pick mark as pending review: the tab gets a blue ● that stays when you look at it, so you know which work you still have to check. Pick mark as reviewed to take it off. Sending the agent a new prompt, or answering a question it asks you, takes it off by itself too, since you are working on it again. With the prefix key, m does the same on the pane you are in, and a stops at marked agents too. Scripts and agents use cornercase mark.

Both ● and ✓ are saved with the session: after a restart or an update, an agent that comes back in its conversation comes back with its mark.

cornercase uses OSC 7501 reports first, including for other recognised agents. Without a report, it uses these readers. Nothing is installed and none of the agents’ settings change.

Claude Code: the small file it keeps for each running session in ~/.claude/sessions (or in $CLAUDE_CONFIG_DIR/sessions), the same one claude agents --json reads. Without that file, for example with an older Claude Code, cornercase falls back to the title Claude gives the terminal, which only tells working from idle.
Codex: the title Codex gives the terminal, which starts with a spinner while it works and with [ ! ] Action Required while it waits for an approval, and the session’s rollout file (the one behind the context line), which records when each turn starts and ends. If you take the activity out of Codex’s terminal title (its /title setting), the tab still shows working and finished, but not !. Verified against Codex CLI 0.160.0.
Gemini CLI: its dynamic terminal title, ✦ or ⏲ while working, ✋ when action is required, ◇ when ready. Keep ui.dynamicWindowTitle enabled and ui.hideWindowTitle disabled: a fixed or hidden title gives no status or notifications. The session file cannot reliably distinguish working from finished.
GitHub Copilot CLI: the open-sessions-state.json in its home (~/.copilot or $COPILOT_HOME), which says whether it is working, and the events.jsonl of the session its process holds open, which says whether a permission prompt, a question or a plan is waiting for you. Ctrl+C or Esc ends the turn; a command it started in the background keeps the tab working.
opencode: the database where it saves its sessions, ~/.local/share/opencode/opencode.db, the same one behind its context line. The tab is working from the moment you send a message until the reply ends or you interrupt it. opencode doesn’t save a pending permission or question anywhere, so while it waits for you the tab still shows ◐ and you get no !; you are told when it finishes. Verified against opencode 1.18.35.

A tab without an agent status shows its shell instead, in grey, so every tab’s name starts in the same column:

Icon	Means
`▸` grey	A program runs in the tab, such as `yarn dev`, a build or an editor.
`›` grey	The shell waits at its prompt.

They never show on the workspace, project or group rows, and a program that ends in another tab gets no ✓. Other agents show as programs.

How full the context is

Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI and GitHub Copilot CLI tabs show their model and the share of the context window used on a second line. The percentage turns orange from 75% and red from 90%. In the compact layout the line sits at the bottom of the tab’s row; long model names are shortened to fit. The model and the percentage are separate switches, settings → UI → model and settings → UI → context: turn one off to keep only the other, such as 23% alone, or both to give every tab one row, unless it shows its memory.

GitHub Copilot CLI shows the model it selected (auto until it has picked one) and the input tokens of its newest main usage record over its prompt limit; a compaction, a truncation, a clear or a model change hides the percentage until its next reply, and sub-agents never change it.

Codex uses the model recorded in its session and last_token_usage.total_tokens divided by its reported model_context_window, for example gpt-5.4 · 20%. Cached input and reasoning tokens are already included; lifetime token totals are not used. This is the share used out of the reported window, rather than Codex’s own remaining percentage, which subtracts a fixed baseline.

Codex's model and current context use, from that pane's own session.

cornercase follows the rollout file held open by the Codex process in each pane, including the native child of an npm wrapper. Sessions in the same folder keep their own numbers. Recent Codex versions hand sessions to a background codex app-server that writes every rollout; then cornercase picks the session by folder, and only when one Codex runs in that folder: with two, neither shows a line, and after one exits the other’s line comes back within about a minute. The line appears after your first message, when Codex creates the session. The files are under $CODEX_HOME/sessions or ~/.codex/sessions, using the running agent’s environment. No hooks or changes to Codex’s settings are needed. This format was verified against Codex CLI 0.160.0.

After a model change or compaction, Codex’s old percentage disappears until fresh usage is recorded. If the window size or current usage is unavailable, only the model appears. A new session, process exit, missing rollout, or an ambiguous association clears the line. On Linux cornercase reads /proc; on macOS it uses the system /usr/sbin/lsof and process metadata. If access to these is unavailable, or Codex runs remotely or in a container, the line is omitted.

opencode shows the same numbers as the bottom of its own screen: the model’s name, such as DeepSeek V4 Pro · 12%, and the tokens of its last answer (input, output, reasoning and cache) divided by the model’s context window. The names and windows come from the list of models opencode keeps in ~/.cache/opencode/models.json; a model it doesn’t list, such as one from a provider you added yourself, shows its id without a percentage. After switching models, the new one shows without a percentage until it answers; after /compact, the percentage is the summary’s, as in opencode.

opencode saves every session of every opencode you run in one database, without saying which process each belongs to, so cornercase picks the session by folder: the one in the folder where that opencode runs, used since it started. The line appears after your first message, and follows /new once you send something there. With two opencode in the same folder, neither shows an icon or a line until one exits. The database is the one the running opencode has open (also with OPENCODE_DB or XDG_DATA_HOME set), read without changing it.

Gemini CLI shows its model ID, such as gemini-3.8-flash, and the input tokens of its newest reply over the model’s window (1,048,576 tokens, or 256,000 for Gemma 4). Its session is found by folder under <GEMINI_CLI_HOME or HOME>/.gemini/tmp; two Gemini sharing that home and folder hide the line. /clear starts a new session. Model switches show the new ID without an old percentage when Gemini records the change or its labelled /model footer column is visible, including with a hidden workspace or trailing context and quota columns. /compress replaces the history without recording fresh usage, so the percentage disappears until the next reply. Hidden or truncated model footers cannot reveal an unsaved picker change.

Once Claude has answered, a second line under the tab’s name shows its model and how much of its context window the conversation takes up, such as Opus 5.5 · 23%: the percentage Claude Code gives its own status line. It turns orange from 75% and red from 90%. After /compact or /clear the line goes away until Claude’s next answer. In the compact layout it sits at the bottom of the tab’s row.

The numbers come from the end of the conversation’s transcript, which Claude Code keeps in ~/.claude/projects (or in $CLAUDE_CONFIG_DIR/projects): the model of the last answer and how many tokens it was sent. The size of the window isn’t written anywhere, so cornercase works it out the way Claude Code does:

1M for the models with a 1M window of their own, such as Opus 5.5, Sonnet 5.5 and Fable 5.1;
1M when the model is chosen with [1m], like sonnet[1m], in --model, in ANTHROPIC_MODEL or in model in Claude’s settings;
200k with CLAUDE_CODE_DISABLE_1M_CONTEXT set, and the value of CLAUDE_CODE_MAX_CONTEXT_TOKENS for models Claude Code doesn’t know;
otherwise 200k, or 1M once the conversation is past 200k.

The variables are read from the running claude and from the env of its settings. After switching models with /model, the percentage can be off until the new model is also in one of those places.

Subagents still running

Claude Code and GitHub Copilot CLI can end their own turn while subagents they started in the background are still at work, and carry on when those report back. Until the last one ends, the tab keeps showing the agent as working (◐), and its second line says how many are left, such as Opus 5.5 · 23% · 2 subagents. Normally the tab turns ✓ and notifies you once, when the last one ends; before, it could show ✓ and tell you the agent had finished when it hadn’t. A subagent that stays silent for 10 minutes (stuck in one long tool call, say) stops counting, so the tab can then turn ✓ early and notify again when it really ends. A question from the agent still shows ! first, and a program that reports its status with OSC 7501 decides on its own.

cornercase wait (--until turn-over included), restart --when-idle and the Telegram and Discord notices wait for the subagents too, and status shows working (2 subagents) and a subagents count. A subagent that has written nothing for 10 minutes stops counting, so one that crashed can’t hold the tab for good; and after you interrupt the agent with Esc, the subagents that stopped at that moment don’t count. Claude Code’s teammates and workflows are not counted (Claude Code reports those itself). Codex, Gemini CLI, opencode, Grok Build and Cursor CLI are not covered: see Limitations.

How much memory a tab uses

Turn on settings → UI → memory and every tab also shows how much memory it uses: at the end of an agent’s line, Opus 5.5 · 23% · 1.2 GB, and on a second line of its own in a shell tab, 412 MB, or just 1.2 GB with the model and the context off.

It is the memory held by everything running in the tab’s panes: each shell and whatever runs in it, such as an agent and what the agent started (MCP servers, language servers, background commands) or a dev server and its workers. In a split tab every pane counts. Each process counts only what it keeps on its own (on macOS, the figure Activity Monitor shows in its Memory column; on Linux, its private memory, including what was swapped out), so code that several processes share, such as the agent’s own program, is not counted again for each of them, and the total is close to what the agent costs you. It is measured every 2 seconds, only for the project on screen (in the tree, for every workspace you have open) and only while the setting is on. In a narrow column the model is shortened first, then left out; the percentage and the memory stay.

Gemini icons need its dynamic window title (ui.dynamicWindowTitle on, ui.hideWindowTitle off). Its session file has no reliable turn-end marker, so a fixed or hidden title gives no status.

Notifications

When an agent asks you something or finishes in a tab you aren’t looking at, cornercase also tells you (opencode only when it finishes):

a toast in the bottom right corner says which agent and where, such as ! claude needs you in web-shop › main or ✓ codex finished in web-shop › main;
your terminal shows a desktop notification, so you find out while you are in another window.

cornercase waits a second before telling you, so a question answered at once stays quiet, and it tells you once each time. The tab on screen doesn’t notify you, even while cornercase’s window is in the background, and neither does one that a program that draws cornercase shows (A view of your own).

The desktop notification is an escape sequence that cornercase writes to your terminal, the way it copies to your clipboard, so it also arrives when cornercase runs on another machine over SSH. When cornercase starts, it asks your terminal for its name and looks at variables such as TERM_PROGRAM, then picks what that terminal understands:

Terminal	Notification
Ghostty, WezTerm, Warp, Rio, foot before 1.18 and Konsole before 24.12 (or when they don’t say their version)	OSC 777
iTerm2	OSC 9
kitty, Contour, VS Code, foot 1.18 or later, Konsole 24.12 or later	OSC 99, shown only while the terminal isn’t focused
Any other, or cornercase inside tmux, screen or Zellij	A bell, which most terminals turn into a sound or a mark on the window

Some terminals, such as Ghostty on macOS, foot, Konsole and Warp, don’t show a notification while their window is in front; the toast tells you then.

Clicking a notification

In kitty, VS Code, Contour, foot 1.18 or later and Konsole 24.12 or later, clicking the desktop notification of an agent that needs you or finished takes you to it: cornercase shows its project, workspace and tab and focuses its pane. If the notification covered several panes of one agent in a workspace, it goes to the one that still needs you. If none of its panes is left open it shows the workspace, and if that is gone too it says so in a toast.

Scripts and other programs do the same with cornercase go TOKEN (Follow events).

The toast has a go button that does the same, in any terminal and also inside tmux, and it stays 6 seconds instead of 2. In Ghostty, iTerm2 and WezTerm a click on the notification only brings the window forward; when you come back to it, the toast shows again with its go if that agent still needs you and isn’t already on screen.

When you quit, restart or stop the server, cornercase closes the notifications it sent, where the terminal can, so a click later doesn’t type anything into your shell. Each attached cornercase gets what its own terminal understands. To choose one yourself, or to turn them off, use settings → UI → desktop notifications; the toast and the marks stay either way. If none shows up, see No desktop notification shows up.

A sound

cornercase also plays a sound at those moments, one for an agent that needs you (or failed) and another for one that finished, so you can tell them apart without looking. It is played on the computer the window is on, not through the terminal, so you hear it while Ghostty on macOS is focused, when it hides the notification, and inside tmux, screen or Zellij. With cornercase remote it plays on your laptop. A window opened in a plain SSH session (ssh -t host cornercase) plays none: that cornercase runs on the other computer.

sound when it needs you and sound when it finishes take a file of your own; empty plays the built-in one. By default only the agents you started make a sound: those started by another agent or by a flow stay quiet, with their toast and notification, unless you turn on sound for subagents. To stop it, turn off settings → UI → sound. See sound for the players it uses and the formats they read.

Usage and stats

The dialog opens on Stats and remembers your last tab until the server restarts. Switch to Limits to read your plan limits. Claude Code and Codex plans have a five-hour session limit and a weekly limit. To see how close you are without opening /usage or /status in one of your agents, click Usage at the bottom of the projects column. Gemini CLI has no section: API keys have no plan limits, and its Google-login quota has no usable CLI probe; use Gemini’s /stats or /usage. opencode has no section: it uses whichever providers you set up, its own Zen and Go subscriptions among them, and cornercase doesn’t ask any of them for your usage.

One section per agent, one bar per limit, with when it resets. Claude's week is orange: it is getting close.

Each installed Claude Code or Codex gets its own section, and each limit shows how much you have used and when it resets. The bar, a thin line, is green, orange when you get close and red at the limit. A weekly limit for one model, when your plan has one, gets its own bar, and Claude Code’s extra usage or Codex’s credits show below them when you have some. Accounts without plan limits, such as an API key, Bedrock or Vertex, say so, and a Codex that isn’t signed in says not signed in · run codex login. With accounts, each account gets a section of its own after the usual login’s, titled by its name, and the one new tabs use is marked with ●.

The numbers come from the agents themselves: showing the Limits tab runs claude and codex in the background, on the machine where cornercase’s server runs, and asks each for its usage (Codex through codex app-server). That sends no prompt and costs no tokens, and cornercase never reads your login. It takes a second or a few; meanwhile each section shows loading…, or the last numbers with how old they are. Nothing is asked while the dialog is closed. An agent that isn’t installed has no section, unless neither is: then both show, each saying why it couldn’t run. agent_commands says where to find one that isn’t on the PATH. done or Esc closes the dialog. To read them from a script or another app, run cornercase usage. If a section says usage unavailable, see Usage is unavailable.

Stats counts only Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI and GitHub Copilot CLI running inside cornercase, from when this feature was installed. It never imports the agents’ histories, including older Grok Build sessions. Cursor CLI keeps no token counts on disk, so for it Stats shows agents, prompts, turns and time, and no tokens. For GitHub Copilot CLI, input is what its usage records report minus the tokens served from the cache. The columns show the current hour and the 23 before it (24 h), 168 hours (7 days) and total. These are rolling windows, independent of your time zone.

How much your agents worked, and how much of it they did side by side.

Row	What it counts
agents started	Each agent process you start, including a manual resume. A conversation restored after a server restart counts no new start.
prompts	Prompts the agent recorded, including scripts, issues, queued input and Claude’s slash commands. Claude’s `!` shell input is excluded.
turns	Transitions from working or waiting to idle, done, pending review or a background shell. A turn whose subagents still run ends when the last of them does.
agent time	Time working, summed over agents. Background shells left running do not count.
most at once	The largest number working at one read.
waited for you	Time waiting for an answer or done in a tab you have not seen. opencode reports no waiting, so only its unseen done time counts.
tokens out	Generated tokens, including thinking and reasoning.
tokens in	Uncached input and cache writes, which the model processes in full.
tokens from cache	Input served from the cache.
merged PRs	Pull requests and merge requests you opened that were merged in a repository of one of your open projects, by merge time. Shown only when `gh` or `glab` can read them.

The merged PRs row asks your own tools, never a token of cornercase’s. gh auth status lists every GitHub account you are logged in to (each host and each login), and for each of them one search finds the pull requests it merged; glab auth status --all does the same for GitLab, one account per host. Only pull requests of repositories that one of your open projects has as a remote count, matched by host and path (a remote through an SSH alias such as github.com-work is matched by its path alone), and one pull request found by two accounts, two projects or two remotes counts once. All three columns count merges since cornercase began counting, the same period as counting for n days, so the 24 h and 7 days columns match the other rows and total is never smaller than them. A + after a number (12+) means some account could not be read or a search passed GitHub’s limit, so the real number may be higher. The row is hidden until one account has been read: when gh and glab are missing, not logged in or too old, or when no project has a remote. The numbers are read when the server starts, every 15 minutes and when you open Stats with data older than five minutes; they are kept in memory only, so cornercase stats with no server running leaves the row out. Turn it off in Settings → Worktrees → merged PRs in stats. Accounts that are not the active one are read with the token gh auth token --user prints, passed only to the search; cornercase never switches your active account.

The headline compares agent time with time when at least one agent worked: 3.4× in parallel means 3.4 hours of agent work per busy hour. It appears after a minute of busy time. Samples arrive every half second, with a two-second cap per interval so sleep and stalls add no long gap. Records count once across reader resets and resumed conversations; Claude’s subagent tokens count too. Nothing is priced in money.

Each heatmap square is a 24-hour block, newest at the bottom right. Rows are not weekdays. Up to 26 weeks fit, and every block shows: grey when no agent worked, including the days before counting began; blue otherwise, with four levels of agent time from the nonzero blocks’ quartiles. The count of days is whole 24-hour blocks since counting began.

share copies a link to a stats card: a ticket with a holographic finish that tilts as you move the pointer over it, or drag it on a touch screen. The page makes a PNG of it in your browser, with download, copy and supported share options. The card shows the same rows as the Stats tab for the window you pick, so the link holds those numbers for the three windows, plus busy time, counting days and heatmap levels. The merged PRs row goes on the card only when every account was read; a + count is never shared. Anyone with the link can see these numbers. It omits agent breakdowns, models, projects, paths and names. The fragment after # is never sent to the site, which has no analytics; nothing is uploaded. Attach the downloaded PNG to posts: link previews show an example card.

The local numbers live in stats.json. To start over, delete that file with the server stopped. cornercase stats reads the same numbers for scripts, even with no server running.

Reorder

To move a project, group, workspace or tab, press on its row and drag it. A cyan line shows where it will land, and it moves there when you release the button.

dotfiles on its way into work, between web-shop and orders-api.

Groups move among the groups, with their projects.
Projects move among the projects, also into and out of groups. Drop one on a group’s header to put it first in that group (last, if the group is collapsed), between a group’s projects to put it there, or among the projects at the top to take it out of its group. The line is indented when the project lands in a group.
Workspaces move within their project, and tabs within their workspace.

A click still selects the row: the drag only starts once the mouse leaves it. Press Esc, or release the button outside the list, to cancel. When the list doesn’t fit, holding the drag over ↑ n more or ↓ n more scrolls it.

The order is kept in your saved session, so it survives a restart.

Rename

Click the ⋯ at the end of a project, group, workspace or tab row (it shows while you hover the row), or right-click the row, to open its menu, then choose rename:

Type the new name and press Enter. Leave the name empty to go back to the automatic one: the folder name for a project, the branch for a workspace, the program for a tab. A group always has a name, so an empty one keeps the current name.

Open in another app

The menu of a project or a workspace row (⋯ or right-click, in every layout) ends with open in…. It opens a second menu with what your computer has: Finder on macOS or your file manager on Linux, then VS Code, Cursor, Zed and Sublime Text, each only when it is installed:

A project opens its folder. A workspace opens its own folder, so for a worktree that is the checkout under ~/.cornercase/worktrees, one click away instead of a path to type.
The pane menu has the same entry for the folder the program in that pane is in, following your cd; the files panel opens the file you are reading, and a right-click on a file or folder in its tree opens the same menu.
A command on your PATH is enough for an editor (code, cursor, zed, subl; on Linux Zed’s command is often zeditor). On macOS an app in /Applications or ~/Applications works without its command.
It opens on the computer your window is on. In a window from cornercase remote, your phone’s browser or an ssh session, the folders are on the other computer, so the menus show copy path instead, which copies the folder’s path to your clipboard. If an app can’t start, the toast says could not open in VS Code: exit status 1; see troubleshooting.

Close

Hover a group, project, workspace or tab row: it gets a lighter background, so you can see what a click will hit, and a × appears at its right end. Clicking it closes that item and ends every program inside it, except on a group, which asks whether to keep its projects open or close them too. In the compact layout the × is always there, and closing a tab or a workspace asks first too:

You close	What happens
A tab	Its panes’ programs are ended, then the tab goes away. In the compact layout it asks first.
A workspace	All its tabs are closed, then the workspace goes away. In the compact layout it asks first. A workspace with its own worktree asks first, because it also deletes the worktree folder; see Removing a worktree.
A project	It asks first, saying how many tabs it stops. Then everything in it is closed and the project goes away; its folder and its worktrees stay on disk.
A group	It asks first, then the group goes away. With keep projects its projects stay open, ungrouped, and nothing in them is ended; with close projects they close with it, which stops every shell in them (folders and worktrees stay on disk).

Rows disappear once their programs have exited, not before. Closing the last tab keeps its workspace (the pane says no tab open), closing the last workspace keeps its project, and closing the last project leaves cornercase open and empty: the pane shows the cornercase logo and that + New opens a folder. Closing every project of a group keeps the group.

When a program ends by itself, for example when you type exit, its pane closes; when the last pane of a tab closes, so does the tab.

Arrange the columns

Scroll a column with the mouse wheel when it has more rows than fit. ↑ n more and ↓ n more tell you what is hidden, and the + buttons stay at the bottom.
Resize a column by dragging the border on its right. The panes follow live. Double-click a border to reset that column to its default width.
Pick a layout in settings → UI → sidebar:
- projects_on_top (the default) puts both lists in one column, the projects above the active project’s workspaces, so the panes get the most room;
- workspaces_on_top swaps the two;
- side_by_side gives each list its own column;
- tree shows one list with every project, its workspaces and their tabs.
Between stacked lists, drag the line to share the height, and double-click it to split it in half again.
Borders that drag (column borders, the line between stacked lists, the line above the agents section and the dividers between panes) light up cyan under the mouse. In Ghostty, kitty (0.31 or later) and foot the mouse pointer also turns into a resize arrow there, ↔ on a border between columns and ↕ on a line between rows, and keeps it while you drag, even off the border. Releasing the button or pressing Esc ends the drag where it is. Other terminals, and cornercase inside tmux, screen or Zellij, keep their usual pointer: see The resize pointer.
Move the tabs above the pane with settings → UI → tabs set to top: see Tabs above the pane.
Turn the buttons into icons with settings → UI → icon bar: see The icon bar.
The active project and tab are marked with a cyan bar ▌ on the left edge and a highlighted background; the active workspace’s name is brighter than the others. Each workspace’s tabs hang from it on thin tree lines.

Column widths, the line between stacked lists, the height of the agents section and what is collapsed are saved with your session. On a small terminal the columns shrink to leave room for the panes, and below 90 columns cornercase switches to a compact layout.

Projects on top: both lists in one column, and the panes get the room of the second one.

The tree

With settings → UI → sidebar set to tree, one list holds your groups, every project, their workspaces and their tabs, indented one step per level. A tab in another project is one click away, and the agents of every open project show what they are doing at once.

The tree: expand what you work on, collapse the rest.

Click ▾ to collapse a project or a workspace and ▸ to expand it again. A click on the rest of its row opens it and expands it. Group headers collapse as everywhere else.
A collapsed project shows how many workspaces it has, and ! or ✓ when something inside needs you; a collapsed workspace shows the most urgent status of its agents, working ones included. Open rows leave that to their tabs.
The cyan bar ▌ on the left edge marks the tab on screen, or the row that hides it while collapsed. Tabs hang from their workspace’s arrow on thin tree lines.
Each project ends with + New (new workspace or start a flow…, for that project) and each workspace with + Tab: adding a tab under another project switches to it.
Drag rows to reorder them: projects among projects and groups, workspaces within their project, tabs within their workspace, as in the other layouts.
What you collapse is saved with your session. Opening a project or a tab from search, or switching to it, expands the way to it.

Below 90 columns the compact layout shows its usual menu, projects then workspaces.

Tabs above the pane

With settings → UI → tabs set to top, a workspace’s tabs leave the sidebar and sit in a bar above the pane, like an editor’s, and only the active workspace’s show there. The sidebar keeps groups, projects and workspaces, so more of them fit; in the tree, it ends at the workspaces.

Tabs on top: the sidebar keeps projects and workspaces, and the bar shows the active workspace's tabs.

Each tab shows its status and its name, and a split tab how many other panes it has (+2); the one on screen sits on a highlighted background. Click a tab to show it, hover it and click ⋯ for its menu or × to close it, and click + to open a shell.
The second line shows the model, the context and, if turned on, the memory of the pane you are in, in grey; a shell shows only its memory, if turned on. The model, context and memory switches apply as on the sidebar’s tab rows.
Both lines are always there, so switching tabs never resizes the terminal.
When the tabs don’t fit, ‹ and › at the ends and the mouse wheel scroll them; the tab you switch to always comes into view.
Drag a tab sideways to reorder it; right-click it, or use its ⋯, to rename it.
A workspace row still shows ! or ✓ when one of its tabs needs you.

Below 90 columns the compact layout lists the tabs in its menu, as always.

The agents section

Turn on settings → UI → agents section to list every Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI and GitHub Copilot CLI running in any project at the bottom of the sidebar, one row per agent:

Every agent in one list: click one to jump to it.

Each row shows what the agent is doing with the same icons as its tab, its project, and its workspace when the project has more than one (a flow’s members show their role instead, see below). Below that: claude, codex, gemini or opencode, its model and how full its context is, as on the tab (the model and context settings apply here too).
Click a row to jump to that agent: its project, workspace and tab open and its pane gets the focus, even in a split tab, whatever project you were in. In the tree the way to it expands.
Right-click a row to mark that agent as pending review, or as reviewed, without leaving the tab you are in; on an agent that started others it also offers collapse or expand.
The agent on screen is marked with the cyan bar ▌.
Rows keep the order of the sidebar, so they don’t move under your pointer; the icon tells you which one waits. When no agent runs, the section says no agents running instead of disappearing.
Agents started by another agent hang under it. An agent that starts others with cornercase start, new-tab or split from its own pane, or a flow’s orchestrator, gets them listed right below it, indented, with ├ before each one and └ before the last, like a workspace’s tabs. Agents under one parent, and the parents themselves, keep the order of the sidebar. An agent you started yourself, or one whose parent is no longer an agent cornercase lists (its pane closed, or it went back to a plain shell), is a row of its own at its place in the sidebar’s order: when a parent closes, the agents under it move back up rather than hanging under the parent’s parent. The tree is drawn at most three levels deep (one in a sidebar under 20 columns); deeper agents line up at the last level, still in order. Who started whom is saved with your session, so the tree comes back after a restart.
Collapse an agent’s team. An agent that started others has a muted ▾ before its status icon: click it to fold the agents under it into its row, and ▸ to show them again (or right-click the row for collapse and expand). A click on the rest of the row still jumps to the agent. A collapsed row shows how many agents it hides (+4) and, when one of them needs you, its icon (!, ● or ✓; working ones say nothing), so a team you put away can still call you. A new agent started under a collapsed one stays hidden and only raises the count. Jumping to a hidden agent, with the keys menu’s a, a notification, go or cornercase focus, opens the way to it, and collapsing the agent you are on moves the ▌ up to the row that hides it. Folds are saved with your session, and cornercase collapse --pane ID and expand --pane ID do the same from a script.
A flow’s team goes by its roles. The members of a flow share its workspace, so their rows would all read the same. Each one hangs under the orchestrator and shows only its role: coder, reviewer, security. The orchestrator keeps its project and workspace and adds · orchestrator when the sidebar is wide enough. A member whose orchestrator is no longer listed shows its place and then its role, and an agent a member started looks as any other. Renaming a tab doesn’t change a role.
Drag the line above it to make it taller or shorter, and double-click the line to go back to a third of the room. Its height is saved with your session.
In a narrow sidebar the model goes first, then the role that follows a project and workspace, then the workspace; the icon and the project stay.

It works in every layout: below the projects in side_by_side, below both lists when they are stacked, and below the tree. Below 90 columns it is a third menu. Only Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI and GitHub Copilot CLI are listed, since other agents don’t report what they are doing.

The icon bar

Turn on settings → UI → icon bar to move the buttons at the bottom of the sidebar (Issues, Changes, Files, TODO, Settings, Usage, Quit, and Remote, the update and the accounts when they show, plus Flow while the workspace runs a flow) into a narrow column of icons on the left edge, like an editor’s activity bar. The lists then reach the bottom of the window. Off by default.

The panels and Issues are at the top; Settings, Usage and Quit at the bottom, with Remote and an available update above them. A button that doesn’t apply, such as Changes outside a git repository or Flow in a workspace that runs no flow, is left out and the others close up.
Hover an icon to see its name beside it, such as Changes 3.
The panel that is open is marked with the cyan bar ▌ and a cyan icon. Click its icon again to close it.
The number of changed files sits at the corner of the Changes icon, in a circle (9+ from ten on); TODO gets a grey dot while items are left to do, and Remote a green one while a browser is attached or you are away on Telegram or Discord.
With it on, the compact layout’s top bar, the search bar and the search buttons of the changes and files panels use the same icons.

The icons come from Nerd Fonts. Ghostty, kitty and WezTerm include them, so they show without installing anything; in another terminal, install a Nerd Font and pick it as your terminal’s font, or the icons show as empty boxes. The size of an icon is your terminal’s choice: a program can only say which character goes in a cell.