Configuration
Codee works with tasks providers to fetch tasks from them. After you run uv run codee-start you need to open Codee UI and open Settings.
uvx codee-agent init asks for most of this in the terminal — the coding agent, the max
parallel tasks, and, for Jira, every credential below. See Installation.
Coding agent configuration
Codee supports Claude Code, GitHub Copilot, Codex and OpenCode coding agents. You can use several of them at once, with a different agent for different tasks, and pick one as the default.
Default agent
Skills run on this agent unless they set their own. To give one skill a different agent,
set its Agent field, which is saved as x-codee-agent in the skill's frontmatter. If
you change the default here, every skill without its own agent switches to it. Skills that
set their own agent are not affected.
Max parallel tasks
Codee can execute multiple tasks in parallel. Specify number of parallel tasks here.
Claude Code
Only shown when the claude CLI is installed on the machine Codee runs on.
Use specified accounts - Auto accounts rotate
A Claude subscription is metered in two windows: a rolling session one and a weekly one. Once either is used up every run fails until it resets, which for an executor that polls around the clock means hours of tasks that simply do not get done.
Switch this on and connect one account per subscription, and Codee carries on through it. Codee checks the current account's usage every five minutes. When a window is full, it signs Claude Code in as the next account that still has allowance. Accounts are used in the order they are listed, and after the last one Codee goes back to the first.
Leave the option off and Codee never touches the credentials file: Claude Code runs on whatever account the machine is signed in with.
Accounts are credentials, so they are kept in Codee's SQLite database rather than in
settings.json — the same place the Azure DevOps tokens live, and for the same reason.
Only the on/off switch is in the settings file.
Connecting an account
Connect a Claude account opens Anthropic's sign-in page. Approve it there, and the page prints a code; paste that back into Codee and the account appears in the list, named by the email it was granted by. The link is shown as well as opened, so the sign-in can be approved from whatever machine you are actually sitting at.
This is the same sign-in as claude /login, and rotation needs it. A token from
claude setup-token only has the user:inference scope, so Codee cannot tell whose
account it belongs to or how much allowance is left. Rotation needs both answers, and a
session token from this sign-in gives them.
Watching them from the Dashboard
With this on, the Dashboard grows a Claude accounts panel: one row per connected account, with a meter for the session window and one for the week, and the account currently doing the work lit up.
Tasks provider configuration
Jira and Azure Dev Ops currently supported. Choose one of them.
Jira settings
For Codee in Jira you need to create a separate user account. So it acts as a real user.
Base URL
Your Jira domain, e.g. https://myjira.atlassian.net.
API Token Owner Email
The email the API token below belongs to. Jira Cloud's REST API authenticates with HTTP Basic where the username is that email, so it is required.
API token
API token to access Jira. Create a separate API token in Codee account settings.
Project key
The short prefix on every issue key in the project, not the project's name — for issue
MYPRJ-4124 the project key is MYPRJ. Jira shows it under Project settings → Details,
and it appears in the URL of any board. Codee polls this one project only.
Azure DevOps
For Azure DevOps you will need to create an App Registration, you will see instruction on the Settings page on how to do that.
Organization URL
Specify your organiztion URL in Azure DevOps.
After you specified Organization URL fill in fields based on app registration:
- Application (client) ID
- Client secret
- Directory (tenant) ID (optional)
Then click Connect to Azure DevOps. You will have to grant access for your app and after that the setup is done.
Work items
Codee only picks up the work items listed here. Each row maps one of Codee's work items to the work item types it stands for in your provider.
You do not need to create anything in Jira or Azure DevOps for this. Point story and
task at the work item types your projects already use, and add a row for anything else
you want Codee to work on. You can still make a separate work item type just for Codee if you
prefer it that way, but Codee does not need one.
Every row says how its work item is found, and the control beside it picks which of the two ways:
Types — pick one or more work item types from the dropdown. If your team works bugs
the same way it works tasks, map task to both Task and Bug, and every task skill will
pick up either one. The same work item type cannot be used in two rows: an
item of that type has to resolve to one set of skills.
JQL (Advanced) / WIQL (Advanced) — a condition you write yourself, which replaces
the type list. Use it when a list of type names is not enough, for example a Bug that is
only Codee's when it has a certain label. Write just the condition, not a whole query:
issuetype = Bug AND labels = "codee" # Jira
[System.WorkItemType] = 'Bug' AND [System.Tags] CONTAINS 'codee' # Azure DevOps
Codee does not check the condition when you save it. Use Verify connection to check it. If the condition is invalid, that work item is not polled at all, so always verify after writing one.
story and task are always present and cannot be removed, because the skills that ship
with Codee trigger on them. You can change the types they are mapped to. By default they
are:
| Codee work item | Jira | Azure DevOps |
|---|---|---|
story | Story | User Story |
task | Task | Task |
You can add more types to either row. If you map story to both Story and Epic, both
are worked by the same story skills.
Load types from provider fills the dropdowns with the types your provider defines.
Use Add work item for anything beyond a story and a task — a bug pointed at your
backend's Bug, say. Add a work item when it needs skills of its own; add another type to
an existing row when it does not.
Codee ignores any work item that no row here selects, whatever state it is in.
Custom JQL / WIQL
An optional condition that narrows every work item query, written in JQL for Jira or WIQL for Azure DevOps. It is empty by default.
| Provider | Example |
|---|---|
| Jira | labels = "codee" AND component != "legacy" |
| Azure DevOps | [System.Tags] CONTAINS 'codee' |
You can also filter by assignee here, so Codee only picks up work items assigned to it.
Write assignee = "codee@yourcompany.com" for Jira, or [System.AssignedTo] = @Me for
Azure DevOps, where @Me is the account that authorized the connection.
Verify connection
Once every field of the selected provider is filled in (and, for Azure DevOps, the app is connected), a Verify connection button becomes available at the bottom of the Tasks provider section.
Clicking it pulls tasks the same way Codee does when it polls: same account, same work item types, same statuses your skills trigger on, and the same custom filter if you set one. It reports either the tasks it found or the reason the provider refused, for example a wrong project key or an expired token. Nothing is saved by verifying, so you can check credentials before storing them.
Once the MCP server is set up, verifying runs a second check through it: the coding agent creates a work item and then closes it again, so you can see that Codee can write to your provider as well as read from it.
Setting up MCP server for tasks provider
When you have set up a task provider you will have button Setup MCP Server activated. In order to work for Codee you should also click
this button. That will configure mcp server for the selected provider in .mcp.json file.