→Aixgo Code · Open source · Beta

An autonomous coding agent that runs inside your GitHub, not ours.

File an issue, apply one label, and get a pull request that a human still has to merge. Everything executes in your own GitHub Actions, on your runners, with your secrets. Aixgo hosts nothing and never sees your code.

Status

Beta. Current release v0.5.0. Two loops run end to end: issue to pull request, and fix-on-request. Expect rough edges.

Install it → Read the source on GitHub → (opens in a new tab)

Your own GitHub App. Your runners. Your model provider key.

Apache-2.0 · Your runners · A human merges every pull request

Apache-2.0
Open source licence
0
Lines of your code reach Aixgo
3
GitHub App permissions: contents, pull requests, issues
1
Label (ax:go) is the only human trigger

01The blocker

The blocker on AI coding agents is not capability. It is what they can reach.

Blast radius

An agent that can merge has an unbounded blast radius. The question is not whether the model is good enough. It is what the model is allowed to reach.

Drift

An ungated loop wanders. It breaks things, and then reports success, because nothing in the loop is qualified to disagree with it.

Security review

Evaluations die in security review. A pilot that has to send your source code to a vendor runtime never gets past the person who signs off on it.

So put the agent inside your GitHub instead of sending your code out of it.

02What it is

Issue in. Reviewed pull request out. A human merges.

Your team describes work in a GitHub issue and applies one label. The agent implements the change on a branch, runs the quality gate your repository already has, and opens a pull request when that gate passes. If a reviewer requests changes, a fixer role addresses them and pushes back to the same pull request.

It proposes. It does not dispose. Nothing about the merge decision moves. Configuration is one file, .github/aixgo.yml, and the only key without a default is the gate.

Driving it by comment

Commands address your own App, not ours, because App names are globally unique and every installation has its own handle. If you installed an App called acme-code, your team types @acme-code go.

  • @your-app goOn an issue, starts work on it, the same as applying ax:go.
  • @your-app addressOn a pull request, addresses the current review feedback.
  • @your-app helpLists what it understands.

You apply one label. The bot owns the other five.

Only a person merges.

  • ax:go Start work on this issue. The only trigger a person sets. Set by You
  • ax:queued Accepted, waiting to start. Set by Bot
  • ax:working Implementing the change. Set by Bot
  • ax:review Review and fix pass in progress. Set by Bot
  • A human reviews the pull request and merges it. Only then does the bot close the issue. Human
  • ax:blocked Needs a human. The agent stopped and left a note. Set by Bot
  • ax:done The bot is finished. A human merged the pull request; the bot closes out the issue. Set by Bot

An issue sits in one state at a time. The prefix is configurable with labelPrefix, and defaults to ax.

03How it works

Five steps, and the fifth one is yours.

  1. Human

    File and label

    Someone writes an issue and applies ax:go. That label is the only thing a person applies to start the work.

  2. Agent

    Implement, then run your gate

    The agent works on a branch and runs the repository's own quality gate, using the gate's output to guide each retry until it passes or it stops and asks for a human.

  3. Agent

    Open the pull request

    Once the gate passes, the agent opens a pull request and hands it back. That is the strongest action available to it.

  4. Human · Agent

    Review, and fix on request

    A reviewer requests changes. A fixer role reads the feedback, makes the changes, re-runs the gate, and pushes back to the same pull request. Only feedback left against the current head is addressed, so the loop never re-litigates a comment it already handled.

  5. Human

    Merge

    A human merges. The agent does not. There is no code path by which it could.

Triggers

ax:go on an issue
@your-app go
A submitted review
@your-app address

Jobs

aixgo-code run
aixgo-code address

Outcome

A pull request opens. A human merges it.

A plain comment in the conversation box is not a review. To run the fixer from a review, submit it through Files changed → Review changes. Every path checks that the person has write access before anything else happens.

Required

gate: is required in the config. A repo with no gate is refused, on purpose.

An agent loop with nothing to stop it will wander, break things, and still report success. The gate is the safety mechanism, so its absence is treated as a configuration error rather than a default to paper over. Getting the gate right → (opens in a new tab)

04Where it runs

Your runners. Your secrets. Your branch protection. #

It can open a pull request against a branch. That is the strongest action available to it. Everything below is checkable in the repository rather than taken on our word.

The deployment model

No Aixgo control plane.
There is no Aixgo-hosted service managing your repositories. When your team installs the App and adds the workflow, the work runs on your runners inside your account.
Your code stays in your repos.
Aixgo never receives it.
Your secrets stay in your secret store.
Model provider keys and the App's private key are read by your own Actions runs and never transit our infrastructure.
Your minutes, your bill.
A reusable workflow runs with the calling repository's own variables and secrets, so you bring your own endpoint and key and pay for your own tokens.
One audit signal.
Everything the agent does appears under your own App's [bot] account. That bot is the single thing to audit.

Five questions to ask of any coding agent

Can it merge its own work?
No. The GitHub interface it is built against has no merge method. The capability is absent from the code, not forbidden by a prompt.
Does it hold deploy credentials?
No deploy credentials and no path to production. Your branch protection rules decide what happens once the pull request exists.
Is the gate mandatory?
Yes. A repo with no gate is refused rather than defaulted.
Can we read the source?
Yes, under Apache-2.0. You are free to read, audit, use and fork it.
Whose model provider account?
Yours. Your endpoint and your key, billed to you, never inherited from Aixgo.

The GitHub App permissions, exactly

Contents

Read the repository and push to a branch.

Pull requests

Open and update a pull request. Not merge one.

Issues

Read issues and manage the ax:* labels.

Not granted

Workflows

It cannot add or change anything under .github/workflows/.

Administration

It cannot touch repository or branch protection settings.

Environments

It cannot reach a deployment environment.

Secrets

It cannot read or write repository secrets.

What it can never do

  • Merge a pull request, its own or anyone else's.
  • Deploy, release, or reach anything in production.
  • Change a workflow file, or the branch protection that guards it.
  • Send your code to Aixgo. There is nothing on our side to send it to.

Proof, in the repository

SECURITY.md → (opens in a new tab)

05Built in the open

Read it before you trust it.

Nine files worth opening. Each one is the answer to a question this page could otherwise only assert.

STATUS.md

What works today, stated plainly.

(opens in a new tab) docs/faq.md

Getting the gate right, with real onboarding examples.

(opens in a new tab) docs/decisions/

Every architectural decision, including 0002-no-merge-path.

(opens in a new tab) docs/setup.md

The whole install in one place, CLI through first pull request.

(opens in a new tab) loop/goal.json

The machine-gradable contract the project builds against.

(opens in a new tab) Makefile

The gate we hold ourselves to, in the repo that ships the agent.

(opens in a new tab) .github/workflows/check.yml

The required check. Same shape we ask you to point the agent at.

(opens in a new tab) LICENSE

Apache-2.0, in full.

(opens in a new tab) SECURITY.md

How to report a vulnerability, and what happens next.

(opens in a new tab)

06Install

Six steps, and you own all of them.

Before you start

  • GitHub Actions on the repository, with minutes to spend.
  • Your own model provider key. Codex on Azure OpenAI is what the reusable workflow runs today.
  • A gate you trust: one command that fails when the code is wrong.
Terminal 
go install github.com/aixgo-dev/code/cmd/aixgo-code@v0.5.0
aixgo-code version

With v0.5.0 that prints 0.5.0. Pin the tag you have validated rather than floating on @latest: pre-1.0 minor versions may still change behaviour.

.github/aixgo.yml
labelPrefix: ax

gate: make check

The gate command is the required key. Everything else has a default.

Evaluate it without letting it touch anything

aixgo-code run owner/repo#12 --dry-run

That runs the whole loop, including the model and your own gate. It makes no GitHub writes and never pushes; it prints what it would have done instead. Separately, aixgo-code init --workflow writes a self-test that proves, in your own runner, that the token is denied Actions administration. The install fails if that denial does not hold.

Install into your GitHub

  1. Create your own GitHub App You

    App names are globally unique, so it cannot be named after ours, and its private key is what mints the tokens that act on your repository. Grant Contents, Pull requests and Issues only. Disable the webhook: the App is an identity, not a delivery target, and there is no Aixgo server to receive deliveries.

  2. Run aixgo-code init --workflow

    That writes .github/aixgo.yml, writes .github/workflows/aixgo.yml pinned to a released reusable-workflow tag, and creates the ax:* labels through your local gh auth.

  3. Fill in the real gate

    Set gate: in .github/aixgo.yml to whatever your repo already runs to know a change is good.

  4. Add the four repository values

    Variables AIXGO_GH_APP_CLIENT_ID and AIXGO_AZURE_OPENAI_ENDPOINT, secrets AIXGO_GH_APP_PRIVATE_KEY and AIXGO_AZURE_OPENAI_API_KEY. The private key must be the full PEM, BEGIN and END lines included.

  5. Open the setup pull request and merge it yourself You

    Setup files are written locally by aixgo-code init and merged by a human, because the runtime holds no workflows permission and cannot add its own workflow files.

  6. File an issue and apply ax:go

    Reviews submitted on the resulting pull request call back into the same reusable workflow for the fix-on-request loop.

Full setup walkthrough → (opens in a new tab)

07Configuration

Four keys, and one of them is not optional.

  • gate Required The command that decides whether a change is good. The one key with no default.
  • review: true Turns on the read-only reviewer. It comments; it never approves and never merges.
  • prDescription: rich Adds a generated walkthrough, a changes table and a sequence diagram to each pull request body.
  • attribution: false Drops the Co-Authored-By trailer and the pull-request footer the agent adds by default.

On engines: Codex on Azure OpenAI is what the reusable workflow runs today. engine: claude is written and tested and works for local CLI runs, but the workflow still installs only the Codex CLI, so GitHub Actions cannot use Claude yet. The loop, the roles and the gate are identical either way.

08Status

Beta, and honest about it.

v0.5.0

Two loops run end to end via the CLI on the Codex-on-Azure engine: issue to pull request, and fix-on-request. v0.5.0 is the latest release and you should still expect rough edges. If you are evaluating it now, read that as beta software rather than a polished product.

  • The issue-to-pull-request loop.Done
  • The fix-on-request loop: a human requests changes, a fixer role addresses them.Done
  • Wiring the read-only reviewer role into the loop, so a diff is reviewed before it reaches a human.In progress
  • The self-onboarding flow via init and init --workflow.Done
  • The Codex on Azure OpenAI engine adapter.Done
  • Self-hosted models on Hugging Face.

Releases → (opens in a new tab) STATUS.md → (opens in a new tab)

09Fit check

It is not for everyone, and that is not a disclaimer.

Worth your time if…

  • You have a backlog of small, well-specified changes and nobody free to do them.
  • Your repository already has a quality gate you would let decide whether a change is good.
  • Your security position is that source code does not leave your accounts.
  • You want implementation help without giving up the merge button.
  • You would rather read the code than take a vendor's word for what it can reach.

Not for you if…

  • You want an agent that merges its own work. That is the one thing this cannot be configured to do.
  • You have no gate, and no appetite to write one. A repo with no gate is refused.
  • Your work is exploratory rather than specified. The loop needs an issue it can finish.
  • You need a hosted service with a dashboard and an account manager.
  • You need this running on GitHub Actions against Claude rather than Codex on Azure. That path is not wired up yet.

10FAQ

The questions that decide it.

Is it installable yet?

Yes. v0.5.0 is the latest release. Install the CLI with go install, create your own GitHub App, and run aixgo-code init --workflow in the repository you want it working in.

Can it merge or deploy?

No, on both counts, and not because it is told not to. The GitHub interface it is built against has no merge method, and the App holds three permissions: contents, pull requests and issues. Not workflows, administration, environments or secrets. It holds no deploy credentials and has no path to production.

Do you see our code?

No. There is no Aixgo control plane. The agent runs in your GitHub Actions, on your runners, reading your repository with a token your own App minted. Nothing is sent to us because there is nothing on our side to send it to.

Do we need our own GitHub App?

Yes. App names are globally unique, so it cannot be named after ours, and its private key is what mints the tokens that act on your repository. The App is an identity rather than a webhook target: there is no Aixgo server to receive deliveries, so the webhook stays disabled.

Can it change our workflow files?

No. The App is deliberately denied the Workflows permission, so a change under .github/workflows/ has to be a human commit or a local CLI run under your own gh auth. That is also why the setup files are written locally and merged by a person.

Why is a gate mandatory?

An agent loop with nothing to stop it will wander, break things, and still report success. The gate is the safety mechanism, so the tool treats its absence as a configuration error rather than a default to paper over. The engineering that matters here is the gate, not the loop.

What if our CI is not worth trusting?

Then that is the first thing to fix, and it was already costing you before any agent showed up. A check that has only ever been observed green is indistinguishable from no check at all. That is why a repo with no gate is refused rather than given a default.

Which models does it use?

The reusable workflow runs the Codex CLI against Azure OpenAI, with a default deployment of gpt-5.4. The Claude Code adapter is written and tested behind engine: claude, but it is reachable from a local CLI run only: the workflow still installs the Codex CLI alone.

What does it cost?

The software is Apache-2.0 and free. You pay GitHub for Actions minutes and your model provider for tokens, both billed to your own accounts.

Can we contribute?

The source is open under Apache-2.0, so you are free to read, audit, use and fork it. Aixgo Code is not currently accepting external code contributions. Bug reports and security reports are welcome through issues and the process in SECURITY.md.

Read the source, or install it.

The repository is open, Apache-2.0, and in beta. Both of those are the point.

Install it → Read the source on GitHub → (opens in a new tab)

Building agents in Go? Aixgo is the framework →

Apache-2.0 · Issues and security reports welcome · Not accepting external pull requests