CogniRunner Coder: a Jira coding agent that commits to GitHub from the issue
Mihai Perdum
Author
13 min readOctober 2, 2026
Key takeaways
END STATE: a Jira issue whose change sits in a GitHub pull request, opened by CogniRunner Coder after two confirmations, with the commit and the PR linked back on the issue.
Plan mode reads the repository and writes its plan into the issue description. Agent mode stages edits. On the default Auto-edit setting, nothing reaches the repository until you press Confirm on a card that names the branch and every file.
On our run, KAN-1 went from issue to pull request #4 in three turns: a 46.9 s plan, a 54.2 s staging turn, then one card for the commit and one for the pull request.
The Coder is on in every edition when you bring your own AI key. On Atlassian's Forge LLM it needs the Advanced edition (the app labels it Coder) and Claude Sonnet 5 or Opus 5.
It does not run your code itself. GitHub Copilot for Jira and Atlassian's Jira Coding Agent work in an execution environment; this one works through the GitHub and Bitbucket APIs, from the issue, and can read the build status your own CI reports.
CogniRunner Coder is a Jira coding agent that reads a GitHub or Bitbucket repository from inside the issue, stages edits in the conversation, and, on its default setting, commits them to a branch or a pull request only after a confirmation that names every staged file. I wrote an issue on our demo site on the evening of 1 October, asked it to plan and then do the change, and pressed Confirm twice. This is what GitHub said afterwards. The repository is private, so swap in your own owner/repo when you run these.
1title: KAN-1: let getNextSteps take a limit (1-50)
2state: OPEN
3author: leanzero-srl (Leanzero SRL)
4number: 4
5url: https://github.com/leanzero-srl/cognirunner-forge-offshoot/pull/4
6additions: 13
7deletions: 1
8auto-merge: disabled
9--
10Opened from the CogniRunner Coder workspace.
(Empty fields like labels and reviewers trimmed.) Thirteen lines added, one removed, two files. Small on purpose. I wanted to see every step. A big diff impresses nobody who has to review it.
Everything below ran on our production build, the one Marketplace customers get. That evening it was 5.1.0, header v1.26.9 in the app. About an hour after I finished, production moved to 5.2.0, header v1.26.14. The Coder panel was already in 4.1.0. The workspace, staging, and the one card that commits the whole staged set reached Marketplace customers in 5.0.0 on 30 September. 5.2.0 did change the Coder, and one change touches step 4 below. A new conversation now starts with no repository and a searchable list grouped by workspace. You can also ask the Coder in the chat to list the allowed repositories or work in one. It also added a Sessions list and a way to delete a session. The modes, the permission setting, staging, the commit form, the cards and the links on the issue didn't change. I checked every label I quote against both builds.
Note
Prerequisites
A Jira Cloud site with CogniRunner installed, and a Jira admin for the connection step. Only an admin can add a git connection.
The Coder switched on. On your own AI key (OpenAI, Anthropic, Gemini, Azure, OpenRouter, Bedrock, LM Studio, Ollama and others) it's on in every edition. On Atlassian's Forge LLM it needs the Advanced edition (the app labels it Coder) and Claude Sonnet 5 or Opus 5 as the Coder model.
A GitHub personal access token that can write to the repository, or for Bitbucket an Atlassian API token plus its account email.
A repository you're happy to get a branch in, and an issue that describes a small change.
The gh CLI, if you want to check the result from GitHub's side the way I do in the last step.
What this Jira coding agent does with your GitHub repo
It reads files through the GitHub API, keeps its edits in the conversation, and writes to the repository only when you confirm, unless someone switches the conversation to Bypass, or the site runs the Coder on Goose Swarm (more on that below). That's the whole model.
There's no sandbox and no runner. Every call to GitHub or Bitbucket is a plain backend request from the app, so the Coder never builds or tests anything. It told me so itself, once per turn. I'll come back to what that costs you when I compare it with GitHub Copilot for Jira.
I set it up on our demo site with our own Anthropic key. That's the simplest way in, and the setup card says why: "This site pays for its own tokens, so the edition and the model are yours to choose." If you'd rather not hold a key at all, our tutorial on CogniRunner providers walks through the key versus Forge LLM choice, and I won't repeat it here.
Step by step: from a Jira issue to a GitHub pull request
1
Check that the Coder is on
in Jira, open CogniRunner from the apps menu, then Agents, then Setup. The first card has to read "Coder is on".
2
Add the GitHub connection
on the same page click "+ Add connection", pick GitHub, paste the token, list the allowed repositories as owner/name, choose "Site token" or "Users sign in", and click "Save connection". Then press "Test" on the saved row.
3
Connect your own GitHub session
optional. Open "Your setup", find "Your git sessions" and click "Connect GitHub", so the commits carry your name instead of the token's account.
4
Open the Coder on the issue
on the issue, open "View app actions" and choose "CogniRunner Coder". On 5.2.0 a new conversation starts on "No repository yet": pick yours in the "Repository" list, or send without one and the Coder asks which, or finds it among the allowed repositories. Creating a new repository needs a Jira admin to confirm it.
5
Run a Plan turn
click "Plan", pick the suggestion "Plan the change this issue asks for" and press "Send". Read the plan before you go on.
6
Stage the edits in Agent mode
click "Agent", tell it to go ahead, and check the files under "Changes".
7
Request the commit and the pull request
in Changes open "More ways to commit", choose "Commit and open a pull request…", fill in the branch and title, and click "Send the request".
8
Confirm each card
read the "Needs your OK" card for the commit and press "Confirm", then do the same for the pull request.
9
Verify the result on GitHub and in Jira
check the branch and the pull request with gh, and the comment and links on the issue.
The sections below go through each step with what I actually saw.
Check that the Coder is on
Agents, then Setup. The card on top answers the question before you waste a token.
Agents, then Setup, on our demo site on the day of the run (header v1.26.9, Marketplace 5.1.0). Notice the first line: with the site's own Anthropic key the Coder is on, whatever the edition.
On 5.2.0 the connection on this tab also gets an "Allowed repositories" header with "+ Add repository", and a "Remove" button on each repository row. An admin can change the allow-list without pasting the token again. My capture is from the evening of the run, before the update, so it doesn't show them.
When it's off, the card says why in one sentence and the setup below it is disabled. On a Standard site running Forge LLM the title is "Coder is off - this site is on CogniRunner Standard", and the line under it tells you the two ways out: upgrade the edition, or switch to any bring-your-own-key provider. On the Advanced edition with Haiku in the Coder slot you get "Not a frontier model - it cannot drive an agent here". Haiku doesn't drive an agent on Forge LLM. That's a rule in the code, not a suggestion.
The same card tells you where the Coder lives: "from an issue, open the "View app actions" menu and choose CogniRunner Coder; for a full screen, open the project's "Coder workspace" tab."
Connect GitHub or Bitbucket to the Jira coding agent
The connection form asks for a provider, a label, the credential, the allowed repositories, and who acts on it.
For GitHub the credential is a personal access token. Classic or fine-grained both work. A classic token reports its scopes and the app reads them. A fine-grained one doesn't, so the app can only find out what it may do by trying. The app doesn't publish a list of fine-grained permissions. My reading of GitHub's permissions page, from the endpoints the adapter calls, is Contents read and write plus Pull requests read and write. That's my inference, not the app's statement.
For Bitbucket it's an Atlassian API token plus the account email. The form says it plainly: "Bitbucket app passwords are retired and will not work." If you still have app passwords anywhere, this is how we moved off them. GitHub Copilot for Jira has no Bitbucket side at all, which matters if half your repos live there.
Three rules on this form are worth knowing before you hit them:
The token is checked against GitHub or Bitbucket before it's stored. A dead token is refused at Save, and nobody, admin included, can read a stored token back. The placeholder says it: "Pasted once. It is never shown again."
The allow-list fails closed. The hint reads "An agent may only ever act on a repository listed here. Nothing listed means nothing allowed, on purpose." Up to 200 repositories per connection.
"Site token" means every commit carries the token's account, unless the person connected their own session. "Users sign in" means a session whose owner hasn't connected is refused by name and offered Connect.
Our PR is authored by leanzero-srl, the account behind the site token, because I hadn't connected a personal session. That's the behaviour the form describes. If you want commits under your own name, do step 3: "Your setup", then "Your git sessions", then "Connect GitHub". Atlassian holds that credential for you and CogniRunner never sees it.
Plan mode vs agent mode: read the repo before anything is staged
Start with a Plan turn. I'd do it every time. It costs under a minute and it tells you whether the model understood the issue before it touches a file.
The issue was KAN-1, on a small Forge app that lists your open Jira issues. Its getNextSteps resolver always fetches at most 25 issues. The issue asked for a payload.limit from 1 to 50, with anything else falling back to 25, and a line in the README.
Plan mode on KAN-1, captured on production 5.1.0 on our demo site, unchanged in 5.2.0. Notice the chip next to the mode switch: Reads only. The turn read two files, listed three folders and took 46.9 s.
The plan named both files, the new constant, the exact check it meant to use, and what it would not touch. It also flagged something I hadn't asked about. The app sends every uncached issue to the model in one call capped at 1,200 output tokens, and at 50 issues that reply could be cut off. It said it had not measured the cost per line, so its suggested fix was "a proposal, not a measured figure". I liked that more than the plan. Honestly.
Plan mode changes nothing in the repository. It does write the plan into the issue description, between markers, so the next person reading the issue sees it:
text
1[CogniRunner plan · p_8e0fe7c45086]CogniRunner plan
2Read src/index.js and README.md on main and produced a file-by-file plan for KAN-1: add a validated payload.limit (integer 1–50, default 25 via MAX_ISSUES, new MAX_ISSUES_CAP) feeding maxResults in getNextSteps, plus a short Options section in README.md. Flagged the fixed max_completion_tokens: 1200 in nextStepsFor as a risk at 50 issues and left the Custom UI out of scope. No files were changed.
3[/CogniRunner plan · p_8e0fe7c45086]
Agent turns never touch the description. Only Plan turns write there, inside their own markers.
Next to the mode switch sits a second control, "How much it may do before asking". The default is "Auto-edit": "Staged file edits go through; commits, pushes and Jira writes still ask." "Ask first" puts a card in front of every write. "Bypass" lets edits and commits run without asking, but approvals, deploys and new repositories still need an admin. I left it on Auto-edit. Bypass on a repository you care about is a choice I'd make on a Friday afternoon never.
If your provider is Goose Swarm, our fork of goose that runs on your own machines, Agent turns run on your goose node and report back as signed receipts. Plan mode isn't available there. The turn runs with goose's own tools on your machine, not CogniRunner's. So the allow-list, the cards and the no-runner part of this tutorial are about the other providers. On Goose Swarm, your goose node's own settings decide what it may run and write.
Stage the edits in Agent mode
I clicked Agent. One line: make the two edits, stage them, leave the token budget alone, don't commit yet.
It took 54.2 s. Staging is an edit, so under Auto-edit no card came up. The Changes column showed two files with an M chip each, README.md at 1.6 KB and src/index.js at 5.0 KB, and three buttons: "Commit", "More ways to commit" and "Discard all".
Staged means staged in the app, not in your repository. You can open each file there and read the diff. "Discard all" asks first and puts everything back to what the branch already has.
It repeated the token-cap warning and ended with "Ready to commit when you are". I'd told it not to commit. It didn't.
From Jira ticket to pull request: Commit to branch or Commit and open a pull request
"More ways to commit" gives you two options: "Commit to branch…" and "Commit and open a pull request…". I took the second.
The form came pre-filled. Branch kan-1-coder, built from the issue key, because the conversation was on the default branch. Title "KAN-1: changes from the Coder", which I changed. Description "Opened from the CogniRunner Coder workspace." The line at the top of the form is the important one: "This sends the request as a message, and it runs in Agent mode because committing is an action. The Coder asks you to confirm before anything reaches the repository."
I clicked "Send the request". Within half a minute I had the first card.
The commit card, captured on production 5.1.0 on our demo site, unchanged in 5.2.0. Notice it names the branch, the base, the message and every file, and that the Send button has turned into Queue while it waits.
Branch, base branch, message, repository, and the file list. The commit message body was written by the model, not by me, and it was a better message than I would have written at 22:25. The card doesn't show file contents. It tells you to open Changes for the diff, which is where you should read it anyway.
I pressed Confirm. It committed. "Committed 2 files to kan-1-coder", and the commit landed as 9d66e33. Then a second card came up for the pull request, from kan-1-coder into main, with the title and the body. Another Confirm, and pull request #4 was open.
Two cards, two writes. Annoying the first time, then the part I trust most. Each card is a ticket that runs once, re-checks your role when you confirm, and expires if nobody answers. If the staged files change between the card and your Confirm, the commit is refused as a conflict rather than committing something you didn't read.
Verify the pull request on GitHub and in Jira
Don't trust the chat. Check the branch from GitHub's side.
bash
1gh api repos/leanzero-srl/cognirunner-forge-offshoot/commits/kan-1-coder --jq'{sha:.sha[0:7],author:.commit.author.name,files:[.files[].filename]}'
No error. It parses. That's all node --check proves. I also pasted the new limit line from the diff into node -e and fed it seven values: 10 gave 10, 50 gave 50, and "10" as a string, 10.5, 0, 51 and nothing at all each gave 25. That's what the issue asked for, including the strict reading of "an integer" that the Coder pointed out on its own.
No checks ran on GitHub. None. gh pr checks 4 printed "no checks reported on the 'kan-1-coder' branch". Nothing in this flow runs tests for you.
On the Jira side, KAN-1 got one comment per turn from CogniRunner. The first says "Nothing was staged or committed in this turn", the second lists both files with their sizes, and the third links the commit and the pull request. The issue also got two web links and a markdown transcript attached per turn.
The issue stayed in To Do. The Coder doesn't transition it unless you ask it to.
The links the Coder left on KAN-1, captured on production 5.1.0 on our demo site. Notice they are web links, not entries in Jira's Development panel.
Jira's own Development panel stayed empty on our site. These are web links the Coder writes, not the development information a GitHub integration app feeds Jira. If your team lives in that panel, keep your GitHub integration.
GitHub Copilot for Jira vs CogniRunner Coder: where the code gets written
Copilot for Jira has been generally available since 25 June 2026. GitHub's docs now call the agent behind it Copilot cloud agent; it launched as Copilot coding agent. You assign an issue to Copilot, mention it in a comment, or fire it from a Jira automation, and it works in GitHub Actions and comes back with a pull request. GitHub's docs say it needs a paid Copilot plan, Jira as an AI-enabled app and Rovo activated for your organisation, and it "uses GitHub Actions minutes and AI credits". GitHub only.
Atlassian ships its own, the Jira Coding Agent. It works in a sandbox you can set up with secrets and environment variables, supports GitHub and Bitbucket cloud repositories up to 20 GB, and is "a premium AI feature that consumes Rovo credits". Atlassian says it isn't available yet with Enterprise plans or organisations that require HIPAA, BYOK or data residency.
CogniRunner Coder
GitHub Copilot for Jira
Atlassian Jira Coding Agent
Repositories
GitHub, Bitbucket
GitHub
GitHub, Bitbucket
Where the work runs
the app, through the host's API (Goose Swarm: your goose node)
GitHub Actions
Atlassian's sandbox
Runs your code and tests
no; it can read your CI's result
yes, tests and linters in GitHub Actions
a sandbox with build tools and your setup script
AI
your own key, or Forge LLM on the Advanced edition
Copilot, paid plan
Rovo credits
What a person approves
each write, on a card naming the files (default setting; none on Bypass)
the draft pull request it opens, after the fact
the code in the session, before you create the pull request (or, if you let it push, the draft pull request it opens; it never merges)
6 rows × 4 columnsHeader row enabled
My read. Want the agent itself to run the tests before the pull request? Copilot does that in GitHub Actions. Atlassian's works in a sandbox with your build tools and setup script. Ours doesn't run anything itself. Ours can read the build status your own CI reports on a commit. An admin can have it start a workflow or pipeline after a card, but that's your CI running, not the Coder. Now the other side. Your own AI key, an admin allow-list of repositories, Bitbucket, and a person confirming every write inside the issue on the default setting: that's what we built. Pick by that, not by the brand.
Limits I hit, and what I don't know
A commit takes at most 20 files, 200 KB in total and 64 KB per file. From the issue's own panel, one turn runs per issue at a time. Plan turns keep at most three plans in the description.
I didn't try a personal GitHub session on this run, so the commits here are the token's account, not mine. I couldn't read a per-edition price off the Marketplace listing, so I'm not quoting one. The fine-grained token permissions above are my mapping from GitHub's documentation, not something the app states.
The PR from this run is closed now and its branch deleted, so gh pr view now says CLOSED, and the gh api and gh repo clone commands against kan-1-coder fail. KAN-1 stays on our demo site with its plan, its three comments and its links, if you're ever on a call with us and want to see it.
Key takeaways
You now have a Jira issue whose change is a GitHub pull request, opened by CogniRunner Coder after one card for the commit and one for the pull request.
Plan first: it reads the repository, writes its plan into the description, and changes nothing in the repo.
Agent mode stages edits in the app; on the default Auto-edit setting nothing reaches GitHub until you press Confirm on a card that names the branch and every file.
Verify from GitHub's side with gh, and run your own checks, because the Coder doesn't build or test anything itself.
Not covered here: the Coder workspace page, the headless Coder post-function, and Bitbucket beyond the connection form.
JCMA "We couldn't export Custom Field Config Scheme": three causes, three fixes
