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.
gh pr view 4 -R leanzero-srl/cognirunner-forge-offshoot
js
title: KAN-1: let getNextSteps take a limit (1-50)
state: OPEN
author: leanzero-srl (Leanzero SRL)
number: 4
url: https://github.com/leanzero-srl/cognirunner-forge-offshoot/pull/4
additions: 13
deletions: 1
auto-merge: disabled
--
Opened 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
ghCLI, if you want to check the result from GitHub's side the way I do in the last step.
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.
[[steps]]
gh, and the comment and links on the issue.
The sections below go through each step with what I actually saw.
Agents, then Setup. The card on top answers the question before you waste a token.
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."
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:
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.
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.
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:
[CogniRunner plan · p_8e0fe7c45086]CogniRunner plan
Read 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.
[/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.
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.
"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.
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.
Don't trust the chat. Check the branch from GitHub's side.
gh api repos/leanzero-srl/cognirunner-forge-offshoot/commits/kan-1-coder --jq '{sha:.sha[0:7],author:.commit.author.name,files:[.files[].filename]}'
{"author":"Leanzero SRL","files":["README.md","src/index.js"],"sha":"9d66e33"}
Then pull the branch and run the repo's own check. The Coder said it hadn't built anything, so this is the first time anything checks the code at all.
gh repo clone leanzero-srl/cognirunner-forge-offshoot repo -- -q -b kan-1-coder && cd repo
git log --oneline -2
js
9d66e33 KAN-1: let getNextSteps take a limit (1-50)
fb532f8 chore(cognirunner): install Forge deploy pipeline + permission lock
One commit on top of main. Good. Now the check:
npm run check
> cognirunner-forge-offshoot@0.1.0 check
> node --check src/index.js
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.
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.
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) |
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.
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.
[[takeaways]]
Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.