Linear labels

When you delegate an issue to Delego, the relay reads labels attached to that issue to decide how to route the job — which agent to use, which model, and which repository to work in. These are configured entirely inside Linear using Linear's own label system, so there's nothing extra to install or configure in Delego.

Created for you automatically

You don't have to create these labels by hand. When you connect your Linear workspace, Delego automatically creates the executor, model, thinking, and repo label groups described below, along with their default child labels. Any label that already exists is left untouched — Delego never renames, recolours, or deletes your labels, it only adds the ones that are missing.

If you ever need to recreate them — for example after deleting one by accident — open Linear in the Delego dashboard and click Regenerate labels. It re-runs the same safe, skip-what-exists process on demand.

The repo group is created empty: its child labels are specific to your repositories, so Delego adds the group as a placeholder and leaves you to fill in the values (see the repo section below).

The rest of this page documents what each group means and the values it accepts, so you can apply them to issues and extend them with your own — for example adding a new model child for a model your agent supports.

Label groups

Labels in Delego are structured as label groups: a parent label (the category) with child labels (the values). Delego creates the groups below for you on connect; you can also create or extend them manually in Linear under Settings → Labels. The parent label name is the key Delego reads; the child labels are the values you apply to issues.

executor — which agent runs the job

Delego creates a parent label named executor with the following child labels:

Apply exactly one executor child label to an issue. If two conflicting executor labels are detected, the job is held in a waiting state until you resolve the conflict.

model — which model the agent uses

Delego creates a parent label named model with a starter set of child labels. The value is passed directly to the agent, so each child label is a model identifier the agent accepts:

You can add additional model child labels at any time — Delego passes whatever value you set through to the agent without validation, so any model your agent supports will work. New model versions ship often, so treat the Codex gpt-5.x labels as a starting point and add the exact identifiers your codex CLI accepts.

repo — which GitHub repository the job works in

Delego creates an empty parent label named repo for you. Add one child label per repository you want Delego to target — for example, a label named delegoapp/runner tells the runner to clone and work in the delegoapp/runner repository:

repo
  ├── myorg/frontend
  ├── myorg/backend
  └── myorg/infra

Delego also supports repository mappings configured in the dashboard (under Repository mappings), which can serve as a default when no repo label is present on the issue.

thinking — agent thinking level (optional)

Delego creates a parent label named thinking with the child labels below. It controls the extended thinking budget passed to the agent and is optional — omitting it disables extended thinking.

If an unrecognised thinking value is set, Delego falls back to medium and records a warning on the job.

Label resolution priority

When Delego receives a webhook for a delegated issue, it resolves executor, model, and thinking using this priority order:

1. Issue labels — labels applied directly to the issue take highest priority.
2. Project labels — labels applied to the Linear project the issue belongs to.
3. Workspace default — a default executor configured in your Delego account settings. This applies to executor only.

This means you can set a default executor at the project level and override it on individual issues when needed, without labelling every issue by hand.

Repository resolution

The repo field follows a different path. At enqueue time it is read from issue labels or prompt context, the same as the fields above. If no repo label is found, Delego defers resolution to claim time — when a runner picks up the job, the relay looks for a matching entry in your repository mappings (configured in the dashboard under Repository mappings), matched by the Linear project the issue belongs to. If the project information was missing from the webhook, Delego fetches it from the Linear API and retries the mapping lookup.

Repository mappings are the recommended way to avoid putting a repo label on every issue: map a Linear project to a GitHub repository once in the dashboard, and all issues in that project route there automatically.

What happens when a label is missing or conflicting

If a required field can't be resolved — because a label is missing and no default covers it, or because two conflicting values are present — Delego holds the job in a waiting state rather than failing it outright. The job detail page in the dashboard shows a banner with the exact problem, and the Linear issue contains a link back to it.

To unblock a held job: fix or add the label on the Linear issue, then re-trigger the Agent Session. Delego will pick it up and enqueue it fresh with the corrected values.