Issues and agents

The issue browser turns “I should look at #482” into a running agent in a few clicks: pick an issue, read it, press start. cornercase creates a worktree on a branch named after the issue, opens a tab there, starts your coding agent and hands it the issue.

The result of start: a worktree workspace named after the issue, with the agent and the issue link waiting at its prompt.

Open the issue browser

Click Issues at the bottom of the sidebar. The browser opens for the active project, with one tab per source:

Tab	Shows
All	Every connected source together, most recently updated first.
GitHub	Issues of the project’s repository, read with the `gh` CLI.
GitLab	Issues of the project’s repository, on gitlab.com or your own GitLab server.
Shortcut	Stories from your Shortcut workspace.
Linear	Issues from your Linear workspace.
Jira	Issues from your Jira Cloud site.
Plane	Work items from your Plane workspace, on Plane Cloud or a self-hosted server.
Asana	Tasks assigned to you in your Asana workspace, or the tasks of the projects you choose.

You can hide tabs and change their order in settings → Issues → Sources shown. The browser remembers the last tab you used.

Connect your trackers

GitHub goes through the GitHub CLI, gh, using its own login. There is nothing to configure in cornercase:

gh auth login

cornercase runs gh in the project folder, so it lists the issues of that folder’s repository. The project must be inside a git checkout; otherwise the GitHub tab says this project is not in a git repository.

If gh isn’t on your PATH, set its location in config.json with the gh key.

GitLab needs its server and a personal access token. gitlab.com and self-hosted servers both work.

In GitLab, open Edit profile → Access tokens and create a personal access token with the read_api scope.
In cornercase, open the GitLab tab of the issue browser. Type your server’s address, such as https://gitlab.acme.dev, or leave the field empty for gitlab.com, and press Enter; then paste the token and press Enter. back returns to the server. Type the address the server ends up at: requests carry your token, so cornercase doesn’t follow redirects.

cornercase checks the token against the server and, if it works, saves it. The server is saved in your settings (gitlab_url in config.json), and you can change it in settings → Issues → GitLab, where the token can also be pasted. You can set the GITLAB_TOKEN environment variable instead of saving the token (the name glab uses too, so a token you already export for it works); the server then comes from your settings.

Like the GitHub tab, the GitLab tab lists the issues of the project’s own repository: cornercase reads the repository’s remotes (origin first) and takes the first one on your GitLab server, over SSH or HTTPS, subgroups included. The project must be inside a git checkout; otherwise the tab says this project is not in a git repository. When no remote is on the server, the tab says where the remotes are. A remote that goes through a host alias of your ~/.ssh/config isn’t recognised; add one with the server’s real name.

Shortcut needs an API token:

In Shortcut, open Settings → Your account → API Tokens and create one.
In cornercase, open the Shortcut tab of the issue browser (or settings → Issues → Accounts), paste the token and press Enter.

cornercase checks the token against Shortcut and, if it works, saves it. You can also set SHORTCUT_API_TOKEN in your environment instead.

Linear needs a personal API key:

In Linear, open Settings → Security & access → Personal API keys and create one.
In cornercase, open the Linear tab of the issue browser (or settings → Issues → Accounts), paste the key and press Enter.

cornercase checks the key against Linear and, if it works, saves it. You can also set LINEAR_API_KEY in your environment instead.

Jira Cloud (https://<site>.atlassian.net) needs three things: your site, the email of your Atlassian account and an API token.

At id.atlassian.com, open Security → Create and manage API tokens and create one (a classic token, without scopes).
In cornercase, open the Jira tab of the issue browser. Type your site (acme.atlassian.net, or just acme) and press Enter, then your email and Enter, then paste the token and press Enter. back returns to the previous step.

cornercase checks the token against Jira and, if it works, saves it. The site and the email are saved in your settings (jira_site and jira_email in config.json), and you can change them in settings → Issues → Jira, where the token can also be pasted. You can set JIRA_API_TOKEN in your environment instead of saving the token; the site and the email are still asked once.

The Jira tab lists the issues of the whole site you can see. To narrow it down, set a Jira filter in settings → Issues → Jira: a JQL condition such as project = SHOP, which is combined with the closed and people filters.

Jira Server and Data Center are not supported.

Plane needs your workspace and an API key. Plane Cloud (app.plane.so) and self-hosted servers both work.

For a self-hosted server, first set Plane URL in settings → Issues → Plane to its address, such as https://plane.acme.dev. Empty means Plane Cloud, and the key is checked against the server set there. The server must be recent enough to serve Plane’s /api/v2 work item list.

In Plane, open Profile settings → Personal access tokens and create one.
In cornercase, open the Plane tab of the issue browser. Type your workspace, the part of the address after the server’s name (acme in app.plane.so/acme), and press Enter, then paste the key and press Enter. back returns to the previous step.

cornercase checks the key against Plane and your workspace and, if it works, saves it. The workspace is saved in your settings (plane_workspace in config.json), and you can change it in settings → Issues → Plane, where the key can also be pasted. You can set PLANE_API_KEY in your environment instead of saving the key; the workspace is still asked once.

The Plane tab lists the work items of every project in the workspace you can see. To narrow it down, set a Plane filter in settings → Issues → Plane: query parameters of Plane’s work item list, such as priority=high or project_id=…&label_id=…, which are added to the request together with the closed and people filters. cornercase does not check them: if Plane refuses them, its answer is shown in the list. Plane’s rate limit is 60 requests a minute per key, and a list takes three.

Asana needs a personal access token:

In Asana, open Settings → Apps → Developer apps (or app.asana.com/0/my-apps) and create a personal access token.
In cornercase, open the Asana tab of the issue browser (or settings → Issues → Asana), paste the token and press Enter.

cornercase checks the token against Asana and, if it works, saves it. If your account belongs to several workspaces, it then asks which one to use: type its name or ID and press Enter (back returns to the token). The workspace is saved in your settings (asana_workspace in config.json), and you can change it in settings → Issues → Asana. You can set ASANA_ACCESS_TOKEN in your environment instead of saving the token; with several workspaces, set the workspace in the settings too.

Without further settings the Asana tab lists the open tasks assigned to you. To list the tasks of some projects instead, set Asana projects in settings → Issues → Asana to their IDs or links, separated by spaces or commas; links copied from Asana’s address bar, in the old and the new format, are turned into IDs. In that case the people filters work on the tasks of those projects. Subtasks, milestones and approvals are not listed. A task’s key is the value of its ID field (ENG-42) when its project has one, and its number otherwise. Asana allows 150 requests a minute on free plans, and a list takes at least three.

Saved tokens go to secrets.json next to your config.json, readable only by you (mode 0600). They are never written to logs, to the issue cache or to the screen. The disconnect button in a tracker’s tab removes its saved token.

Browse and filter

Each row shows the issue’s key, its title and, on the right, its state (for closed or tracker states), labels, author and age. Up to 100 issues are listed per source.

Type to filter the list by key, title, author, state, labels or assignees.
↑ ↓, PgUp PgDn or the mouse wheel move through it; Tab and Shift+Tab switch source tabs.
refresh reloads the list. Lists are also cached on disk, so they appear instantly the next time while cornercase fetches the latest.

Two toggles at the top right narrow the list down:

closed includes closed (GitHub, GitLab), done (Shortcut), completed and canceled (Linear), done (Jira) completed and cancelled (Plane) or completed (Asana) issues.
people filters by person, with the fields each tracker has: assignee and author on GitHub and GitLab, owner and requester on Shortcut, assignee and creator on Linear, assignee and reporter on Jira, assignee and creator on Plane and Asana. An Asana list of your tasks is already yours: to filter it by someone else’s assignments, set Asana projects.

For each field you pick anyone, me, or a person from the tracker (type to find them). The filter goes into each tracker’s own search, and cornercase remembers it, along with the closed toggle, the next time you open the browser:

Read an issue

Click an issue, or select it and press Enter, to read it:

At the top you see the issue’s details and its link, then exactly what start will do:

Line	Meaning
start	Where the work happens: in its own worktree and on which branch, or in a new tab.
agent	Which agent will be started, in which mode, and its full command line.
prompt	What will be pasted into the agent, and whether it is sent for you or left for you to send.

Below comes the description, rendered from Markdown (Jira, Plane and Asana descriptions and comments are converted to Markdown first; Asana images show as [image]): headings, lists and task lists, tables, quotes, links and code blocks with syntax highlighting in your terminal’s colours, then the comments.

Scroll with the wheel, ↑ ↓, PgUp PgDn, Space, Home and End.
raw shows the original Markdown; rendered goes back.
copy url copies the issue’s link to your clipboard.
back, Esc or ← return to the list.

Start working on it

Press start in the issue, or select an issue in the list and press start there. cornercase then works out three things.

After schedule (see Schedule for later), start a flow, in the list or in the issue, gives the issue to a whole team of agents instead, a coder, reviewers and a tester run by an orchestrator agent, with the same prompt and the same branch; see Flows.

Where

GitHub and GitLab issues belong to the project you opened the browser from.
Shortcut, Linear, Jira, Plane and Asana issues aren’t tied to a repository, so when more than one place is open, cornercase asks where…: every project that is a git repository is offered as a new worktree, and the workspaces of other projects as a new tab. The place you are in is marked where you are.

In a repository, the issue gets its own worktree on a branch named after it:

Source	Example issue	Branch
GitHub	#482 Returns page crashes on empty address	`issue-482-returns-page-crashes-on-empty-address`
GitLab	#482 Returns page crashes on empty address	`482-returns-page-crashes-on-empty-address`
Shortcut	sc-48 Dark mode	`sc-48-dark-mode`
Linear	ENG-123 Returns page crashes	`ENG-123-returns-page-crashes`
Jira	SHOP-77 Returns page crashes	`SHOP-77-returns-page-crashes`
Plane	ENG-42 Fix login redirect	`ENG-42-fix-login-redirect`
Asana	ENG-42 Fix login redirect	`ENG-42-fix-login-redirect`
Asana, no ID field	1205555555555555 Fix login redirect	`asana-1205555555555555-fix-login-redirect`

GitLab branches start with the issue’s number and a dash, GitLab’s own convention: a merge request from such a branch gets Closes #482 in its description, so, with the project’s automatic issue closing on (GitLab’s default), the issue closes when the merge request is merged into the default branch.

The title part is lowercased, accents become plain letters, everything else becomes dashes, and it is cut at a word boundary to at most 40 characters. The workspace is named after the issue’s key and title, like #482 Returns page crashes on empty addr….

If a workspace on that branch is already open, cornercase takes you there instead of creating another one, and only starts the agent if the workspace has no tab open. Outside a repository, the agent starts in a new tab of the chosen workspace, and the tab is named after the issue.

Which agent

cornercase picks the agent in this order:

the one you chose for this issue with agent…;
the default agent from settings → Agents;
when the default is auto, the agent already running in your current tab;
otherwise it asks:

When you pick an agent that isn’t your default, a make default button appears so you can keep that choice. Once you have accounts of the chosen agent, start (or Enter) first asks which account it starts with, with the one in use selected, so Enter again keeps it; account… on the issue’s page chooses it ahead. Neither changes the account in use; start a flow passes it on. An account removed before you click start stops the start and says so. How each agent starts (its permission mode and extra arguments) is set in settings → Agents; see Agents.

The launch

Once the worktree exists, cornercase opens a tab in it and drives the new shell for you:

It waits for your shell’s prompt to settle, then types the agent’s command line, for example claude --permission-mode plan, and presses Enter.
It waits until the agent has taken over the terminal and its screen has been still for a moment.
If the agent asks whether you trust the folder, cornercase waits for you to answer: saying yes lets the agent use the repository’s own agent settings, so it is your call. With settings → Agents → trust prompts turned on, cornercase answers yes for you instead.
It pastes the prompt. By default the prompt is your issue’s link, typed on one line and left at the agent’s prompt for you to read and send with Enter. With settings → Agents → send the prompt turned on, it is pasted as written and sent for you.

Readiness is detected from what the terminal shows, so a slow agent may take a few seconds. If the shell still hasn’t started the agent a few seconds after the command was typed, cornercase gives up and leaves the tab as it is; the reason is written to the server log.

Review the result

You don’t need to keep an eye on the agent’s tab. With Claude Code, Codex, Gemini CLI, opencode, Grok Build, Cursor CLI or GitHub Copilot CLI, the tab shows ◐ while it works (or a spinner, with working icon set to spinner), and if it asks you something (Claude Code, Codex, Gemini CLI, Grok Build, or Cursor CLI with /status-indicators turned on or OSC 7501 reports) or finishes while you are elsewhere, the tab, its workspace and its project show ! or ✓, and a notification tells you where; see What your agents are doing.

The issue’s workspace is a git worktree, so its changes panel shows what the agent is doing as it saves files. Open it with Changes next to Issues, switch to All to see the commits too, and hover a hunk to ask agent about it: cornercase types the file and lines into the agent’s prompt for you.

Schedule for later

Click schedule beside start to put an issue in the agent queue, the Queue tab at the end of this dialog. Choose a clock time, delay, or the next Claude or Codex five-hour plan reset. The queue starts each due agent in its chosen worktree or tab and accepts its folder trust question automatically.

From scripts and other apps

Everything above is reachable without the window. cornercase issue sources says which trackers are connected for a project and what is missing, issue list lists issues with the dialog’s filters from the same lists, issue read prints an issue with its comments and issue people the people the filters can name. cornercase start --issue '#482' does what start does: a worktree on the issue’s branch with your prompt template, or a tab when the project isn’t a repository, asking --project or --workspace when an issue isn’t tied to a repository and several places are open. See Scripts and agents.