Certyn can hand a finding to a coding agent. The agent reads the report and its evidence, works in your repository, and opens a pull request for you to review like any other.
Certyn never pushes to your base branch and never merges. The pull request is the handover point.
The agent today is GitHub Copilot's cloud coding agent, so the work runs on GitHub rather than inside Certyn.
What you need
- A GitHub repository, and an account with write access to it.
- A Copilot plan that includes the coding agent. On an organisation repository, an owner also has to enable the coding agent policy and allow that repository.
- Project admin rights in Certyn to connect the repository. Once it is connected, anyone who can edit findings can start a fix.
When the feature is available for your workspace, Coding tasks appears in the top navigation, right after Findings.
Connect a repository
Open Coding tasks
The page owns setup. If nothing is connected yet it opens on a two step wizard.
Authorize GitHub
Certyn cannot offer a list of repositories before it holds a token, so authorizing is its own step. Only the credential is checked here.
Choose a repository and base branch
Pick from the repositories the credential can reach. The base branch is what the agent branches from and targets with its pull request. Certyn checks that both are reachable before saving.
Optional: give the agent access to Certyn
This lets the agent pull the full record of a finding instead of relying only on what the prompt carries. It is two handoffs: Certyn writes the repository Agents secret COPILOT_MCP_CERTYN_TOKEN for you, then hands you a small block of JSON to paste into the repository's Copilot settings. GitHub has no API for that second part.
The MCP entry to add in GitHub looks like this, with your own API host:
{
"mcpServers": {
"certyn": {
"type": "http",
"url": "https://api.certyn.example/api/mcp",
"headers": {
"Authorization": "Bearer $COPILOT_MCP_CERTYN_TOKEN"
},
"tools": [
"get_coding_task_context",
"get_ticket",
"get_execution_detail",
"get_execution_transcript",
"ask_certyn"
]
}
}
}
Fixes still run without it. The prompt carries the whole report, so the agent is never sent in blind. What it loses is the ability to open the session behind the finding: the transcript, the screenshots, and follow-up questions.
Changing the repository later does not rewrite history. Each task records the repository and branch it ran against.
Start a fix
The handoff is in two places, and it is the same control in both:
- On a finding's page, in the Coding agent card in the right sidebar, together with the repository, the run status, and the pull request.
- In any finding list: the dashboard's Needs you list, and the Review and In process tabs under Findings. Click a row to open it. The fix sits under the write-up, next to Open finding.
You do not have to confirm a finding first, and starting a fix does not confirm it. A finding in review is exactly where someone decides it is real and worth fixing, so the handoff is offered before triage as well as after. The agent gets the same report and evidence either way.
It is not offered where it would make no sense: findings that did not reproduce, findings owned by an external tracker, and a finding whose run is still going.
What the agent is told
Every task carries the finding itself: title and report, severity, type, status, the environment and build it was found on, the tracker link if there is one, and a link back to the finding in Certyn. Very long reports are trimmed, with a pointer to the full record.
If Certyn MCP is set up for the repository, the prompt also tells the agent it can read the execution behind the finding, its transcript and its screenshots, and ask Certyn follow-up questions. If it is not, the prompt says so plainly, and asks the agent to write down what it was unsure about in the pull request rather than guess.
Follow the work
| Status | Meaning |
|---|---|
| Queued | GitHub accepted the task and has not started it |
| Running | The agent is working |
| Needs input | The agent asked a question. Answer it on GitHub |
| Succeeded | The agent finished. A pull request link appears when there is one |
| Failed | The run did not finish. The reason is on the finding |
The Coding tasks page lists every task in the project, with All, Active, Succeeded and Failed tabs, and links straight to the pull request.
GitHub's API offers no cancellation, so Certyn cannot stop a run it started. Stop it on GitHub instead. A finding also has at most one active task: starting again while one is running returns the run already in flight rather than opening a second pull request.
When it fails
The Coding agent card shows the reason, with Try again directly under it. In a finding list the same control reads Fix with coding agent again, with a circular arrow, and the reason is in its tooltip.
| What you see | What to do |
|---|---|
| The coding agent is not enabled for this account or repository | A plan and policy state, not a hiccup. Retrying will not clear it. Check the Copilot plan, and on an organisation repository the coding agent policy and the repository allow list |
| GitHub rejected the stored credential | The token expired or was revoked. Reconnect from the Coding tasks page |
| GitHub refused this request | The connected account probably lacks write access to the repository |
| GitHub could not find the repository | It was renamed, made private, or the account's access was removed |
Verify the fix
A merged pull request is not a verified fix. Once the change ships to the environment the finding was found on, open the finding and run Retest. Certyn re-runs it and records the result against the same finding, so the history shows what was found, what was changed, and what a run said afterwards.
From Ask Certyn
You can also ask in chat: "fix issue 12", or "what coding tasks are running?". Ask Certyn can start a task and report on the ones that exist.
This is deliberately chat only. External MCP clients such as Claude or Cursor cannot open a pull request in your repository through Certyn.