# Quickstart: your first gated pull request > Go from sign-up to your first AI change that passed its quality gates and opened a pull request: account, Git, project, session, approval. About ten minutes. Source: https://aicodeops.dev/docs/quickstart · Last updated: 2026-10-18 This guide takes you from a new account to your first AI-written change that passed its quality gates and became a pull request. It takes about ten minutes, most of it the session running. AI CodeOps is in open beta and free to use; it runs in your browser, so there is nothing to install. Each step has an **Open in AI CodeOps** link that takes you straight to the right screen (you sign in first if you need to). ## 1. Create your account (about 1 minute) Choose **Start free** on the site. Continue with GitHub or Google if they're offered, or sign up with your email and a password, then type the 6-digit code we email you. The code expires after 10 minutes. On your first sign-in, AI CodeOps creates a workspace for you. A workspace holds your projects, sessions, members and settings. If someone invited you, you join their workspace instead. Depending on your role, you may be asked to set up two-factor sign-in (an authenticator app or a passkey). See [Members and roles](https://aicodeops.dev/docs/members). ## 2. Connect your Git host (about 1 minute) AI CodeOps works on your repositories through your own Git account. 1. Open **Configure → Settings** and scroll to **Git Providers**. [Open in AI CodeOps](https://aicodeops.dev/open/settings) 2. Pick your host and choose **Connect**, or paste a personal access token and choose **Connect with token**. Guides for each host: [GitHub](https://aicodeops.dev/docs/git/github), [GitLab](https://aicodeops.dev/docs/git/gitlab), [Bitbucket](https://aicodeops.dev/docs/git/bitbucket), [Gitea](https://aicodeops.dev/docs/git/gitea), [Forgejo](https://aicodeops.dev/docs/git/forgejo). What each one is allowed to do: [Permissions and scopes](https://aicodeops.dev/docs/git/permissions-and-scopes). ## 3. Create a project (about 1 minute) 1. Open **Plan → Projects** and choose **New project**. [Open in AI CodeOps](https://aicodeops.dev/open/projects) 2. Enter an **Identifier** (like `billing-api`) and a **Name**. 3. Paste your **Repository URL** and choose **Verify access**, or leave it empty to start from scratch. 4. Choose **Create project**. Every session runs against a project. More in [Projects](https://aicodeops.dev/docs/projects). ## 4. Describe a change and start a session (under a minute, then it runs) 1. Open **Develop → AI Sessions** and choose **New session**. [Open in AI CodeOps](https://aicodeops.dev/open/sessions) 2. Describe a small, concrete task, for example "Add input validation to the signup endpoint and test it." 3. Keep the default workflow, **Plan, Build, Review & Test**, and pick your project. 4. Choose **Start session**. ## 5. Watch the agents plan, build and review (usually a few minutes) The session page shows each step live: the architect plans, the builder writes the change, a review reads the actual diff, and your project's tests run in a sandbox. It runs on the platform's models within your monthly allowance unless your workspace has its own provider key. See [How AI CodeOps works](https://aicodeops.dev/docs/how-it-works) and [Models and tiers](https://aicodeops.dev/docs/models). ![An AI session paused at the approval gate, with its changed files and review findings](https://aicodeops.dev/press/screenshots/02-session-release-gate.png) _Interactive demo, sample data._ ## 6. See the gate pass or fail (about 1 minute) When the session finishes, its page shows: - **Proposed changes**: the diff. - **Quality gates**: your tests' results and whether the change is release-ready. - **Findings**: anything the review flagged, with severity. An open high or critical finding blocks the change until it is fixed or triaged. The change also appears under **Develop → Changes**. More in [Quality gates](https://aicodeops.dev/docs/quality-gates). ## 7. Approve, and the pull request opens (about 1 minute) A review request is waiting under **Review & Gate → Approvals**. [Open in AI CodeOps](https://aicodeops.dev/open/approvals) When a teammate approves it and the gates pass, AI CodeOps opens a pull request on a new branch with the approver's Git connection. Working alone? You can approve your own change until someone else in the workspace can approve. You can then merge it on your Git host, or from the console, which checks the gate again first. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Next steps - [Invite your team](https://aicodeops.dev/docs/members) - [Set a budget](https://aicodeops.dev/docs/cost-controls) - [Set up AI CodeOps with your coding agent](https://aicodeops.dev/docs): every docs page is also Markdown at its URL plus .md - [See what's in each plan](https://aicodeops.dev/pricing) ## Frequently asked questions ### Does AI CodeOps cost anything during the beta? No. It is free during the open beta, with a monthly allowance of AI tokens on the platform's models. You can also connect your own model provider key. ### Do I need to install anything? No. AI CodeOps runs in the browser and sessions run on the platform. There is no CLI or desktop app to install. ### Can I try it without connecting a repository? Yes. Create a project with no repository URL and the agents start from scratch. You need a connected Git host to open a pull request. --- # How AI CodeOps works > Follow one AI CodeOps session from task to merged pull request: agents plan and build, your tests run in a sandbox, AI review flags issues, a person approves. Source: https://aicodeops.dev/docs/how-it-works · Last updated: 2026-10-18 A session takes one task from a sentence to a reviewed pull request. This page follows a session through each stage, in the order AI CodeOps runs them. ## 1. You describe the task Open **Develop → AI Sessions** and choose **New session**. Describe the task, pick a **Workflow** and a **Project**, and choose **Start session**. Every session belongs to a [project](https://aicodeops.dev/docs/projects). Before anything runs, AI CodeOps checks two things: - **Your budget.** If the workspace is over its budget or out of allowance, the session doesn't start and says why. See [Cost controls](https://aicodeops.dev/docs/cost-controls). - **Your workspace policy.** A deny rule stops the session. An ask rule holds it until someone approves it on **Review & Gate → Approvals**. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). The session is then queued with the status **pending** until a worker picks it up. ## 2. The agents work through the workflow A workflow is a fixed list of steps. Each step is run by one agent, and the steps run one after another. The default workflow, **Plan, Build, Review & Test**, runs: 1. **Plan**, by the [Architect](https://aicodeops.dev/agents/architect). 2. **Build**, by the [Builder](https://aicodeops.dev/agents/builder). 3. **Review**, by the [Reviewer](https://aicodeops.dev/agents/reviewer). 4. **Test**, by the [Tester](https://aicodeops.dev/agents/tester). Each step sees the task and what the earlier steps wrote. The budget is checked again before every model call. A session that goes over budget mid-way stops with the reason. Other workflows are listed in [Workflows](https://aicodeops.dev/docs/workflows). ## 3. The change is written Once the steps finish, AI CodeOps turns the team's plan into complete files. It applies them to a fresh copy of your repository and produces a diff. A project without a repository gets a new codebase instead. A diff over 60 KB is refused whole: "Split the task into smaller changes." If no usable file changes come back, the session fails with the reason. ## 4. Your tests run AI CodeOps rebuilds the change in an isolated sandbox. It installs dependencies, cuts the sandbox off from the network, and runs your project's test command. The result is recorded as the session's test run: passed, failed, skipped and coverage. The test command is the one set on the project. Without one, AI CodeOps looks for a `package.json` test script, then pytest, then `go test`. If tests can't run at all (no command, or dependencies that won't install), nothing is recorded and the run page shows that the change wasn't verified. ## 5. The diff is reviewed A review pass reads the actual diff, with the review and security steps' notes as context. It records **findings**, each with a severity, a category and usually a file. See [Multi-agent reviews](https://aicodeops.dev/docs/multi-agent-reviews). If that review can't finish, the change is held: its findings are unknown, so it can't be treated as clean. ## 6. The change waits for a person When the session finishes with a diff, AI CodeOps: - marks the session **completed**; - moves its change to **in review** under **Develop → Changes**; - opens a review request on **Review & Gate → Approvals**. It expires after 7 days. Open the session page to see the summary, the **Proposed changes**, the **Quality gates** panel and the **Findings**. ## 7. A person approves Choose **Accept changes** on the session page, or **Approve** on the Approvals page. The person who started the session can't approve it while someone else in the workspace can. A one-person workspace can approve its own change. One rejection ends the request. ## 8. The pull request opens Approving starts the pull request. Before opening it, AI CodeOps checks, in order: 1. the workspace policy; 2. the approval; 3. the [quality gate](https://aicodeops.dev/docs/quality-gates): no open high or critical findings, no failing tests, and a completed review. If all three pass, AI CodeOps pushes a branch named `codeops/run-` and opens a pull request into the project's default branch. It uses the Git connection of the person who approved, so they need a [connected Git account](https://aicodeops.dev/docs/git/permissions-and-scopes) for that host. If the pull request couldn't open, choose **Create Pull Request** on the session page. The button says what's missing. ## 9. Merge and deploy Merge the pull request when you're ready. If you merge it from the console, the quality gate is checked again first. If the project has a deploy target, AI CodeOps then calls your deploy webhook and records the deployment. See [Gated deploys](https://aicodeops.dev/docs/gated-deploys). ## Time limits | Stage | Limit | | ------------------ | ------------------------------------------- | | Agent steps | 4 minutes in total | | Tests | 6 minutes, plus the command already running | | Review of the diff | 2 minutes | | Whole session | Stopped as stalled after about 19 minutes | A session that times out or stalls ends as **failed**, with the reason on its page. ## Next steps - [Core concepts](https://aicodeops.dev/docs/core-concepts) - [Sessions](https://aicodeops.dev/docs/sessions) - [Quality gates](https://aicodeops.dev/docs/quality-gates) ## Frequently asked questions ### Does an AI session merge code by itself? No. A person approves every code change before its pull request opens, and merging is a separate step you take. ### What if my project has no tests? The session still runs. No test result is recorded, the run page shows that verification was skipped, and nothing about tests blocks the change. ### Can I watch the agents while they work? Yes. The session page updates live with each step, its agent, its status, and the tokens and cost so far. --- # Core concepts > The building blocks of AI CodeOps: organizations, workspaces, projects, agents, workflows, sessions, findings, gates, approvals, changes and deployments. Source: https://aicodeops.dev/docs/core-concepts · Last updated: 2026-10-18 These are the things AI CodeOps works with, and how they connect. Each entry says where to find it in the console. ## Organization The account that owns workspaces, and the unit for plan and seats. Everyone gets an organization the first time they sign in. Manage it under **Configure → Settings → Organization & Teams**. ## Workspace Where your team works: projects, sessions, members, roles and settings. Every workspace belongs to one organization. Workspaces are kept apart in the database, so one can't read another's data. See [Members and roles](https://aicodeops.dev/docs/members). ## Project A codebase AI CodeOps works on, usually linked to a Git repository. It has an identifier, a type, a default branch and a test command. Every session runs against a project. Find projects under **Plan → Projects**. See [Projects](https://aicodeops.dev/docs/projects). ## Agent An AI role with its own instructions, such as Architect, Builder, Reviewer, Tester or Security Auditor. Each step of a workflow is run by one agent. You can define your own agents with their own model, permissions and prompt under **Configure → Agents**. See [Agents and workflows](https://aicodeops.dev/docs/agents) and the [agent pages](https://aicodeops.dev/agents). ## Workflow A fixed list of steps, each run by one agent, for example Plan → Build → Review → Test. There are 16 built-in workflows, listed under **Develop → Workflows**. See [Workflows](https://aicodeops.dev/docs/workflows). ## Session One run of a workflow on one task and one project. In the console it's an **AI session**, under **Develop → AI Sessions**. A session records each agent step, its tokens and cost, the diff it produced and its test result. A session's status is one of: pending, running, completed, failed, canceled, or blocked (by a policy or a budget). A follow-up session is linked to the session it builds on. ## Finding An issue the AI review found in a change. Each finding has: - a **severity**: critical, high, medium, low or info; - a **category**, such as security, quality, performance or test coverage; - a **triage status**: open, acknowledged, in progress, fixed, won't fix, false positive or duplicate. Open high and critical findings block the change. Findings appear on the session page and under **Build & Test → Quality**. See [Multi-agent reviews](https://aicodeops.dev/docs/multi-agent-reviews). ## Quality gate The check that decides whether a change can ship. A change is release-ready when its review completed, no high or critical finding is still open, and no test failed. The gate runs before a pull request opens and before the console merges one. Your CI can ask the same question through the release gate. See [Quality gates](https://aicodeops.dev/docs/quality-gates). ## Approval A request for a person to say yes or no. AI CodeOps opens one for every code change a session proposes, and for actions your policy marks ask. Each has a status: pending, approved, rejected, expired or canceled. Decide them under **Review & Gate → Approvals**. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Change The unit of work, from proposal to production. A change links the session that made it, its approval, its pull request, its deployment and any incident. Its status moves forward: | Status | Meaning | | --------- | ---------------------------------------------- | | proposed | A session started on it. | | in review | The session produced code; it awaits approval. | | approved | A person approved it. | | merged | Its pull request was merged from the console. | | deployed | A deployment of it succeeded. | | abandoned | The session failed or was canceled. | Find changes under **Develop → Changes**. ## Evidence pack A signed record of how one change was made: the task, models, approvals, policy decisions, findings, tests and delivery. Download it from a change's page and verify it in the browser or offline. See [Evidence packs](https://aicodeops.dev/docs/evidence-packs). ## Deployment A record that a version of a project went to an environment. It has a status (queued, in progress, succeeded, failed, rolled back or canceled), a commit or version, and the session that produced it. Find deployments under **Release → Deployments**. See [Gated deploys](https://aicodeops.dev/docs/gated-deploys). ## Next steps - [How AI CodeOps works](https://aicodeops.dev/docs/how-it-works) - [Start a session](https://aicodeops.dev/docs/sessions) - [Open beta FAQ](https://aicodeops.dev/docs/open-beta-faq) ## Frequently asked questions ### Is a session the same as a workflow? No. A workflow is the recipe, a fixed list of agent steps. A session is one run of a workflow on one task and one project. ### Where do I find a change after its session ends? Under Develop → Changes. A change follows the work from proposal through review, merge and deployment. ### Does AI CodeOps deploy my code? No. It calls a deploy webhook you set and records the deployment. Your own pipeline does the deploy. --- # Open beta FAQ > What the AI CodeOps open beta includes: free use, the monthly AI token allowance, your own model key, how your code and data are handled, and what comes after. Source: https://aicodeops.dev/docs/open-beta-faq · Last updated: 2026-10-18 AI CodeOps is in open beta. These are the answers to the questions people ask most about it. For prices and plans, see [Pricing](https://aicodeops.dev/pricing). ## What's free during the beta? Using AI CodeOps. You can run AI sessions on GitHub, GitLab, Bitbucket, Gitea or Forgejo repositories, with tests, AI review, approvals and quality gates, and track cost per session. There is nothing to install: it runs in your browser and sessions run on the platform. ## How much AI usage is included? Sessions on the platform's models draw on a monthly token allowance (input plus output tokens). The allowance is set per model tier: Economy, Standard and Premium. The [pricing page](https://aicodeops.dev/pricing) shows the current amounts. They are read from the same settings the platform enforces. The allowance: - is shared by every workspace owned by the same account; - starts again on the 1st of each month (UTC); - is shown under **Measure → Usage**, in **AI allowance this month**. When you start a session, the **Model tier** list shows what's left in each tier, or "not in your plan" for a tier your plan doesn't include. See [Models and tiers](https://aicodeops.dev/docs/models). ## What happens when the allowance runs out? If the workspace has credits, the session continues on them. Otherwise it stops and says what ran out, for example "Monthly free allowance used". A session never switches to another tier on its own. To keep going, you can: - start the session on another tier; - add credits on the **Billing** page; - connect your own model provider key. ## Can I use my own model key? Yes. Workspace admins can add a provider key on the workspace **Dashboard**, under **Bring Your Own Key**. Anthropic, OpenAI, Moonshot (Kimi), Z.ai (GLM), DeepSeek, Groq, OpenRouter and Ollama Cloud keys can run sessions. Sessions on your own key are billed by your provider and don't use the platform allowance. They still count toward your workspace's [cost budget](https://aicodeops.dev/docs/cost-controls). Keys are encrypted at rest and shown masked. ## How is my code and data handled? - **Training.** Your prompts, code and generated output are never used to train AI models. They are sent to the model provider that runs your session, only to run it. - **Where code runs.** Your tests and every terminal run in their own sandboxed containers, with outbound network access restricted. - **Separation.** Workspaces are kept apart in the database, so one workspace can't read another's data. - **Secrets.** Workspace secrets, provider keys and Git tokens are encrypted at rest (AES-256-GCM). - **Your data.** You can export your account data, or delete your account, from your account settings in the console. The companies that process data for us are listed on the [trust page](https://aicodeops.dev/trust). Retention periods are in the privacy policy. More on [Security](https://aicodeops.dev/security). ## Is there an uptime guarantee? Not during the beta. An uptime SLA will be published at general availability. Live service health is on the status page. ## What happens after the beta? Paid plans will be announced before the beta ends, with notice to every workspace. Nothing is charged unless you choose a plan. Prices haven't been announced yet. ## What about Enterprise? Enterprise is for organisations that need identity, audit and governance controls. It adds: - single sign-on with SAML or OIDC; - custom roles and separation-of-duties roles; - longer audit log retention; - self-hosted deployment on request, for Enterprise customers who need AI CodeOps on their own infrastructure. Enterprise is priced per seat. See [Enterprise](https://aicodeops.dev/enterprise) or the [Enterprise docs](https://aicodeops.dev/docs/enterprise). ## Next steps - [Quickstart](https://aicodeops.dev/docs/quickstart) - [How AI CodeOps works](https://aicodeops.dev/docs/how-it-works) - [Models and tiers](https://aicodeops.dev/docs/models) ## Frequently asked questions ### Is AI CodeOps free during the open beta? Yes. Every workspace can use it free during the beta, with a monthly allowance of AI tokens on the platform's models. ### Will I be charged when the beta ends? Not without choosing a plan. Paid plans will be announced before the beta ends, with notice to every workspace. ### Is my code used to train AI models? No. Your prompts, code and generated output are sent to the model provider only to run your session, and are never used to train models. --- # Connect your Git provider > Which Git hosts AI CodeOps works with (GitHub, GitLab, Bitbucket, Gitea and Forgejo), how each one connects, and what the platform does in your repositories. Source: https://aicodeops.dev/docs/git AI CodeOps works on your code where it already lives. You connect a Git account once, from **Configure → Settings → Git Providers** in your workspace. After that, a session clones the project's repository, writes its change on a new branch and opens a pull request (a merge request on GitLab) for a person to review. Nothing merges without that review. ## Pick your provider | Provider | Hosting | How it connects | Guide | | --------- | -------------------------------------------------------------- | ------------------------------------------------- | ---------------------------------------- | | GitHub | GitHub.com (not GitHub Enterprise Server) | OAuth, or a personal access token | [Connect GitHub](https://aicodeops.dev/docs/git/github) | | GitLab | GitLab.com or a self-managed instance | OAuth, or a personal access token | [Connect GitLab](https://aicodeops.dev/docs/git/gitlab) | | Bitbucket | Bitbucket Cloud (not Server or Data Center) | OAuth (recommended), or a token with limits | [Connect Bitbucket](https://aicodeops.dev/docs/git/bitbucket) | | Gitea | A Gitea server you run | A personal access token and your server's address | [Connect Gitea](https://aicodeops.dev/docs/git/gitea) | | Forgejo | Your own Forgejo server, or a public instance such as Codeberg | A personal access token and the server's address | [Connect Forgejo](https://aicodeops.dev/docs/git/forgejo) | [Git permissions and scopes](https://aicodeops.dev/docs/git/permissions-and-scopes) lists every OAuth scope and token permission AI CodeOps asks for on each host, what it is used for, and how to revoke access. ## What the platform does in your repositories - **Clones** the repository of the project a session works on. - **Pushes a new branch** with the session's change. It never pushes to your default branch. - **Opens a pull request** on that branch. It doesn't merge on its own: a person merges it, from the console or on your Git host. It doesn't register webhooks, post commit statuses or comment on your pull requests. ## Servers you run AI CodeOps runs in the cloud, so a self-managed GitLab, Gitea or Forgejo server needs a public **https** address it can reach over the internet. Addresses on private networks, `localhost` and `.local` or `.internal` names are refused. ## Next steps 1. Connect your provider using its guide above. 2. [Create a project](https://aicodeops.dev/docs/projects) that points at a repository. 3. [Start a session](https://aicodeops.dev/docs/sessions) on that project. --- # Connect GitHub > Connect a GitHub.com account to AI CodeOps with OAuth or a personal access token, the scopes it needs, and what the platform does with your repositories. Source: https://aicodeops.dev/docs/git/github AI CodeOps works on your GitHub repositories through a connection you make once. Sessions then clone the repository, write the change on a new branch and open a pull request for review. ## Before you start - A GitHub.com account with access to the repositories you want to use. - GitHub Enterprise Server isn't supported. For Git servers you run yourself, AI CodeOps supports [GitLab](https://aicodeops.dev/docs/git/gitlab), [Gitea](https://aicodeops.dev/docs/git/gitea) and [Forgejo](https://aicodeops.dev/docs/git/forgejo). ## Connect with OAuth 1. In your workspace, open **Configure → Settings** and scroll to **Git Providers**. 2. On the **GitHub** card, choose **Connect**. 3. GitHub asks you to authorize AI CodeOps. Approve it, and you return to Settings with the account listed under **Connected Accounts**. AI CodeOps asks GitHub for these OAuth scopes: | Scope | Why | | ------------ | ------------------------------------------------------------------------------------------------------------------------------ | | `repo` | Read and write repositories you can access: clone, push a branch, open and merge pull requests. Includes private repositories. | | `read:user` | Show which GitHub account is connected. | | `user:email` | Requested with the sign-in scopes; AI CodeOps doesn't read the address through this connection. | If you see "GitHub sign-in isn't set up on this server", the platform's OAuth app isn't available. Connect with a token instead. ## Connect with a personal access token On the GitHub card, paste a token into **or access token (no OAuth app)** and choose **Connect with token**. AI CodeOps checks the token against GitHub before saving it; a bad token gets "Token rejected — check the URL and key." The token needs to read your user profile, read repositories, push branches, and create and merge pull requests. On GitHub that means: - a **classic** token with the `repo` scope, or - a **fine-grained** token for the repositories you want, with **Contents** and **Pull requests** set to read and write (Metadata read is included). Personal access tokens are not refreshed. When the token expires on GitHub, disconnect and connect again with a new one. ## What AI CodeOps does with the repository - **Browse:** **Develop → Repositories** lists the repositories the account can see, with their branches, files and pull requests. - **Sessions:** a session clones the project's repository into its sandbox and writes the change there. - **Branches and pull requests:** when a change is approved and passes its [quality gates](https://aicodeops.dev/docs/quality-gates), AI CodeOps pushes a branch named `codeops/run-` and opens a pull request into the project's default branch. Commits are authored as "AI CodeOps". - **Merge:** a pull request the console opened can be merged from the console. The release gate runs again first. AI CodeOps doesn't register webhooks on your repositories or post review comments on GitHub. ## Your token and your access - Connections belong to you, not the workspace. Each member connects their own account, and workspace permissions still decide what they can do. - Tokens are encrypted at rest (AES-256-GCM) and are never written into a repository's Git configuration. - To remove access, choose **Disconnect** next to the account. You can also revoke the app or token on GitHub. ## Next steps - [Create a project](https://aicodeops.dev/docs/projects) from a GitHub repository. - [Run your first session](https://aicodeops.dev/docs/sessions). - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) if a connection shows **Expired** or a push is refused. --- # Connect GitLab > Connect GitLab.com or a self-managed GitLab instance to AI CodeOps with OAuth or a personal access token, and see how merge requests are opened for you. Source: https://aicodeops.dev/docs/git/gitlab AI CodeOps works with GitLab.com and with self-managed GitLab instances. Connect an account once; sessions then write changes on a new branch and open a merge request for review. ## Before you start - A GitLab account with at least Developer access to the projects you want to use, so it can push branches and open merge requests. - For a self-managed instance: its public **https** address, for example `https://gitlab.example.com`. The platform has to reach it over the internet. Addresses on private networks, `localhost`, and `.local` or `.internal` names are refused. ## Connect with OAuth 1. In your workspace, open **Configure → Settings** and scroll to **Git Providers**. 2. On the **GitLab** card, leave **Instance URL (blank for gitlab.com)** empty for GitLab.com. 3. Choose **Connect via OAuth** and approve the request on GitLab. AI CodeOps asks for the `api` and `read_user` scopes. `api` lets it read repositories, push branches and create and merge merge requests; `read_user` shows which account is connected. OAuth only works against the GitLab server the platform's OAuth app is registered on (GitLab.com by default). For any other instance you get "GitLab sign-in isn't set up on this server": use a token. ## Connect with a personal access token This is the usual path for a self-managed instance. 1. In GitLab, create a personal access token (**User settings → Access tokens**) with the `api` scope. A project or group access token also works if it has `api` and the Developer role or higher. 2. On the GitLab card in AI CodeOps, enter your **Instance URL** (or leave it blank for GitLab.com). 3. Paste the token into **or access token** and choose **Connect with token**. AI CodeOps checks the token against your instance before saving it. "Token rejected — check the URL and key." means the URL or token is wrong, or the token lacks access. Tokens are not refreshed: when one expires in GitLab, disconnect and connect again with a new one. ## What AI CodeOps does with the repository - **Browse:** **Develop → Repositories** lists your projects with their branches, files and merge requests. - **Branches and merge requests:** when a change is approved and passes its [quality gates](https://aicodeops.dev/docs/quality-gates), AI CodeOps pushes a branch named `codeops/run-` and opens a merge request into the project's default branch. Commits are authored as "AI CodeOps". - **Merge:** a merge request the console opened can be merged from the console. The release gate runs again first. AI CodeOps doesn't register webhooks on your projects or comment on merge requests. ## Your token and your access - A connection belongs to you, not the workspace. Workspace roles still decide what each member can do. - Tokens are encrypted at rest (AES-256-GCM). OAuth tokens are refreshed before they expire. - To remove access, choose **Disconnect** next to the account, or revoke the token in GitLab. ## Next steps - [Create a project](https://aicodeops.dev/docs/projects) from a GitLab repository. - [Run your first session](https://aicodeops.dev/docs/sessions). - Using Gitea or Forgejo too? See [Connect Gitea](https://aicodeops.dev/docs/git/gitea) and [Connect Forgejo](https://aicodeops.dev/docs/git/forgejo). --- # Connect Bitbucket > Connect a Bitbucket Cloud account to AI CodeOps with OAuth so sessions can push branches and open pull requests, plus the limits of token-based connections. Source: https://aicodeops.dev/docs/git/bitbucket AI CodeOps works with repositories in Bitbucket Cloud workspaces. Connect your Bitbucket account once; sessions then write changes on a new branch and open a pull request for review. ## Before you start - A Bitbucket Cloud account with write access to the repositories you want to use. - Bitbucket Server and Data Center aren't supported. ## Connect with OAuth This is the recommended way to connect Bitbucket. 1. In your workspace, open **Configure → Settings** and scroll to **Git Providers**. 2. On the **Bitbucket** card, choose **Connect**. 3. Bitbucket asks you to grant access. Approve it, and you return to Settings with the account under **Connected Accounts**. Bitbucket shows the permissions on its consent screen. AI CodeOps uses them to read your account and repositories, push branches, and create and merge pull requests. OAuth tokens are refreshed automatically before they expire. If you see "Bitbucket sign-in isn't set up on this server", the platform's OAuth consumer isn't available. Contact support. ## Token connections The card also has a token field, **or access token (no OAuth app)**. AI CodeOps sends that token to Bitbucket as a Bearer token. Bitbucket app passwords and API tokens that need your username or email alongside them won't work in this field. If a token is refused with "Token rejected — check the URL and key.", connect with OAuth instead. ## What AI CodeOps does with the repository - **Browse:** **Develop → Repositories** lists the repositories the account can see, with branches, files and pull requests. - **Branches and pull requests:** when a change is approved and passes its [quality gates](https://aicodeops.dev/docs/quality-gates), AI CodeOps pushes a branch named `codeops/run-` and opens a pull request into the project's default branch. Commits are authored as "AI CodeOps". - **Merge:** a pull request the console opened can be merged from the console. The release gate runs again first. AI CodeOps doesn't add webhooks to your repositories or comment on pull requests. ## Your token and your access - A connection belongs to you, not the workspace. Workspace roles still decide what each member can do. - Tokens are encrypted at rest (AES-256-GCM) and aren't written into any repository's Git configuration. - To remove access, choose **Disconnect** next to the account. You can also revoke AI CodeOps's access in your Bitbucket settings. ## Next steps - [Create a project](https://aicodeops.dev/docs/projects) from a Bitbucket repository. - [Run your first session](https://aicodeops.dev/docs/sessions). - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) --- # Connect Gitea > Connect your own Gitea server to AI CodeOps with a personal access token: the instance URL, the token scopes it needs, and how pull requests are opened for you. Source: https://aicodeops.dev/docs/git/gitea AI CodeOps works with Gitea servers you run. You connect with your server's address and a personal access token. Sessions then write changes on a new branch and open a pull request on your server for review. ## Before you start - Your Gitea server's public **https** address, for example `https://gitea.example.com`. AI CodeOps runs in the cloud, so it must be able to reach the server over the internet. - Addresses on private networks, `localhost`, link-local addresses and `.local` or `.internal` names are refused. So are URLs with a query string or `#fragment`. The error says: "Use the public https address of your Git server". - An account with write access to the repositories you want to use. ## Create a token in Gitea 1. In Gitea, open **Settings → Applications** and generate a new token. 2. Give it read and write access to **repository** (to clone, push branches, and create and merge pull requests) and read access to **user** (to show which account is connected). 3. Copy the token. Gitea shows it only once. ## Connect the token 1. In your workspace, open **Configure → Settings** and scroll to **Git Providers**. 2. On the **Gitea** card, enter the **Instance URL**. It is required. 3. Paste the token into **or access token** and choose **Connect with token**. AI CodeOps checks the token against your server before it saves it. "Token rejected — check the URL and key." means the address or the token is wrong, or the token lacks a scope. ## OAuth The card also has **Connect via OAuth**. It only works for the one Gitea or Forgejo server the platform's OAuth app is registered on. For your own server you will see "sign-in isn't set up on this server": use a token. ## What AI CodeOps does with the repository - **Browse:** **Develop → Repositories** lists the repositories the account can see, with branches, files and pull requests. - **Branches and pull requests:** when a change is approved and passes its [quality gates](https://aicodeops.dev/docs/quality-gates), AI CodeOps pushes a branch named `codeops/run-` and opens a pull request into the project's default branch. Commits are authored as "AI CodeOps". - **Merge:** a pull request the console opened can be merged from the console. The release gate runs again first. AI CodeOps doesn't install webhooks on your server or comment on pull requests. ## Your token and your access - A connection belongs to you, not the workspace. Workspace roles still decide what each member can do. - The token is encrypted at rest (AES-256-GCM) and isn't written into any repository's Git configuration. - To remove access, choose **Disconnect**, or delete the token in Gitea. To rotate a token, disconnect and connect again with the new one. ## Next steps - [Create a project](https://aicodeops.dev/docs/projects) from a Gitea repository. - [Run your first session](https://aicodeops.dev/docs/sessions). - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) --- # Connect Forgejo > Connect a Forgejo server, such as Codeberg or your own instance, to AI CodeOps with a personal access token, and see what the platform does with your repos. Source: https://aicodeops.dev/docs/git/forgejo AI CodeOps works with Forgejo servers, whether you run your own or use a public instance. You connect with the server's address and a personal access token. Sessions then write changes on a new branch and open a pull request for review. ## Before you start - The server's public **https** address, for example `https://forgejo.example.com`. AI CodeOps runs in the cloud and has to reach it over the internet. - Addresses on private networks, `localhost`, link-local addresses and `.local` or `.internal` names are refused, as are URLs with a query string or `#fragment`. - An account with write access to the repositories you want to use. - On Codeberg (`https://codeberg.org`), read its [Terms of Use](https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md) first: they don't allow projects that mostly consist of code written by generative AI tools. ## Create a token in Forgejo 1. In Forgejo, open **Settings → Applications** and generate a new access token. 2. Grant read and write on **repository** (clone, push branches, create and merge pull requests) and read on **user** (show which account is connected). 3. Copy the token now. Forgejo shows it only once. ## Connect the token 1. In your workspace, open **Configure → Settings** and scroll to **Git Providers**. 2. On the **Forgejo** card, enter the **Instance URL**. It is required. 3. Paste the token into **or access token** and choose **Connect with token**. AI CodeOps checks the token against the server before saving it. If you see "Token rejected — check the URL and key.", check the address and the token's scopes. ## OAuth **Connect via OAuth** only works for the one Gitea or Forgejo server the platform's OAuth app is registered on. For any other server you will see "sign-in isn't set up on this server": use a token instead. ## What AI CodeOps does with the repository - **Browse:** **Develop → Repositories** lists the repositories the account can see, with branches, files and pull requests. - **Branches and pull requests:** when a change is approved and passes its [quality gates](https://aicodeops.dev/docs/quality-gates), AI CodeOps pushes a branch named `codeops/run-` and opens a pull request into the project's default branch. Commits are authored as "AI CodeOps". - **Merge:** a pull request the console opened can be merged from the console. The release gate runs again first. AI CodeOps doesn't install webhooks on the server or comment on pull requests. It also doesn't read Forgejo Actions results; tests run in the session's own sandbox. ## Your token and your access - A connection belongs to you, not the workspace. Workspace roles still decide what each member can do. - The token is encrypted at rest (AES-256-GCM) and isn't written into any repository's Git configuration. - To remove access, choose **Disconnect**, or delete the token in Forgejo. To rotate it, disconnect and connect again. ## Next steps - [Create a project](https://aicodeops.dev/docs/projects) from a Forgejo repository. - [Run your first session](https://aicodeops.dev/docs/sessions). - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) --- # Projects > Create a project in AI CodeOps: link a Git repository or start from scratch, set the default branch and test command, and see what a project tracks over time. Source: https://aicodeops.dev/docs/projects A project is a codebase AI CodeOps works on. Every AI session belongs to a project, and the project collects what happens to that code over time: sessions, changes, deployments, incidents, SBOMs and decision records. ## Create a project 1. Open **Plan → Projects** and choose **New project**. 2. Fill in the form (fields below). 3. Choose **Create project**. | Field | What to enter | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Identifier** | Lowercase, no spaces, for example `billing-api`. Used in URLs and reports. It can't change later. | | **Name** | A readable name, for example "Billing API". | | **Type** | service, library, frontend, infra, data pipeline, model, docs or other. | | **Repository URL** | Optional. The repository's address, for example `https://github.com/acme/billing-api`. | | **Default branch** | Optional. The branch sessions and the terminal work against. Blank means the repository's own default. | | **Test command** | Optional. Run after a session writes code, against the proposed change, in an isolated environment. Blank means it is detected (a `package.json` test script, else pytest or go test). | | **Health check URL** | Optional. A public https endpoint used by monitoring. | | **Description** | Optional. | ### Checking repository access After entering a repository URL, choose **Verify access**. AI CodeOps tells you whether the repository is reachable and its default branch. If you have a [connected Git account](https://aicodeops.dev/docs/git/github) for that host, private repositories work: "Will use your GitHub account … private repos accessible." Without one, public repositories still clone, but you can't open pull requests. ### Starting from scratch Leave **Repository URL** empty to start a new codebase. Sessions then generate the source on the platform, and you can browse it under **Develop → Source**. When you want to ship it, choose **Add repo** on the project and enter a repository; later changes can then be opened as pull requests. ### Turning off tests Tick **Don't run tests for this project** if it has no test suite. Sessions then skip the test step, and the run page shows that the change wasn't verified. See [Quality gates](https://aicodeops.dev/docs/quality-gates). ## The project page Open a project to see: - **Deployments**, **Open incidents**, **Vulnerable components (latest SBOM)** and **Recent ADRs** at a glance; - an **Activity** timeline of sessions, deployments, incidents and decisions; - **Recent deployments** and **Recent SBOMs**. From here you can **Run workflow** (describe a task and start a session on this project), **Browse source**, **Edit** the project, or **Archive** it. Projects that show up in your SBOMs, decision records or incidents but aren't set up yet appear under **Detected projects** on the projects list, ready to add. ## Archive and restore **Archive** hides a project from the active list. Its history stays, but you can't run sessions against it. Archived projects are listed under **Archived**, with **Restore** to bring one back. ## Next steps - [Run a session](https://aicodeops.dev/docs/sessions) - [Connect a Git provider](https://aicodeops.dev/docs/git/github) - [Security and SBOM](https://aicodeops.dev/docs/security-and-sbom) ## Frequently asked questions ### Can I create a project without a repository? Yes. Leave the repository URL empty and the session's generated code stays on the platform. Add a repository later to ship it as a pull request. ### Can I delete a project? You can archive it. An archived project is hidden and can't run sessions, but its history stays and you can restore it. --- # Git permissions and scopes > The OAuth scopes and token permissions AI CodeOps asks for on GitHub, GitLab, Bitbucket, Gitea and Forgejo, what each is used for, and how to revoke access. Source: https://aicodeops.dev/docs/git/permissions-and-scopes · Last updated: 2026-10-18 AI CodeOps reaches your repositories through a Git connection you make in **Configure → Settings → Git Providers**. This page lists exactly what each connection asks for, what AI CodeOps does with it, and how to take access away. ## What AI CodeOps does with a connection With your token, AI CodeOps: - reads your user profile, to show which account is connected and to check the token when you connect it; - lists and searches the repositories you can access, with their branches, files, commits and pull requests (**Develop → Repositories**); - clones a project's repository so a session can work on it; - pushes a branch named `codeops/run-` and opens a pull request into the project's default branch; - merges a pull request when you merge it from the console. It doesn't create repositories, register webhooks, post commit statuses or comment on pull requests. ## OAuth scopes by host Choose **Connect** (or **Connect via OAuth** on GitLab) on a host's card to connect with OAuth. | Host | Scopes requested | What they're for | | -------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | GitHub | `repo`, `read:user`, `user:email` | `repo`: read and write your repositories, including private ones, to clone, push branches and open and merge pull requests. `read:user`: show the connected account. `user:email` is requested but not used by the connection. | | GitLab | `api`, `read_user` | `api`: read repositories, push branches, open and merge merge requests. `read_user`: show the connected account. | | Bitbucket | Set by the platform's OAuth consumer | Bitbucket lists them on its consent screen. They're used for the same operations as above. | | Gitea, Forgejo | None in the request | The server's default for the OAuth app applies. | GitHub uses an OAuth app, not a GitHub App. OAuth for GitLab, Gitea and Forgejo works only against the server the platform's OAuth app is registered on (GitLab.com for GitLab). For any other server, connect with a token. If OAuth isn't set up, you see "… sign-in isn't set up on this server". ## Personal access tokens Every host's card has a token field: **or access token** (or **or access token (no OAuth app)** on GitHub and Bitbucket). Paste a token and choose **Connect with token**. For GitLab on your own server, Gitea and Forgejo, also enter the **Instance URL**. It must be the server's public https address. Private network addresses and `localhost` are refused unless the platform operator allows that host. The token needs to read your profile, read repositories, push branches, and create and merge pull requests: | Host | Token permissions | | -------------- | --------------------------------------------------------------------------------------------------------------------------- | | GitHub | A classic token with `repo`, or a fine-grained token with **Contents** and **Pull requests** set to read and write. | | GitLab | A personal, project or group access token with the `api` scope. Project and group tokens need the Developer role or higher. | | Gitea, Forgejo | Read and write on **repository**, and read on **user**. | | Bitbucket | Sent as a Bearer token. Tokens that need a username alongside them won't work; connect with OAuth instead. | When you connect, AI CodeOps checks the token by reading your profile. It doesn't check the token's scopes. A token that's too narrow connects, then fails when a session tries to push or open a pull request. "Token rejected — check the URL and key." means the URL or token is wrong. Tokens are not refreshed. When a token expires on your host, disconnect and connect again with a new one. Host guides: [GitHub](https://aicodeops.dev/docs/git/github), [GitLab](https://aicodeops.dev/docs/git/gitlab), [Bitbucket](https://aicodeops.dev/docs/git/bitbucket), [Gitea](https://aicodeops.dev/docs/git/gitea), [Forgejo](https://aicodeops.dev/docs/git/forgejo). ## Whose connection is used A connection belongs to the person who made it, not the workspace. Workspace roles still decide what each person can do with it. When a change is approved, its pull request is opened with the approver's connection for that host. When you merge from the console, your own connection is used. You can have one connection per host type. To switch to another account or server, disconnect first. ## How tokens are stored Tokens are encrypted at rest with AES-256-GCM. They are passed to Git as a request header, never written into the repository's URL or its Git configuration. ## Revoke access 1. Open **Configure → Settings** and scroll to **Git Providers**. 2. Choose **Disconnect** next to the account, then **Disconnect account** to confirm. 3. On your Git host, revoke the token, or the AI CodeOps app under your authorized applications. Step 3 matters: **Disconnect** removes the connection from AI CodeOps but doesn't revoke the token on your host. ## Next steps - [Create a project](https://aicodeops.dev/docs/projects) - [How AI CodeOps works](https://aicodeops.dev/docs/how-it-works) - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) ## Frequently asked questions ### Does disconnecting revoke the token on my Git host? No. Disconnect removes the connection from AI CodeOps. To revoke the token itself, revoke it or the app in your Git host's settings. ### Does AI CodeOps add webhooks to my repositories? No. It doesn't register webhooks, post commit statuses or comment on pull requests. ### Is signing in with GitHub the same as connecting GitHub? No. Sign-in only reads your profile and verified email. Repository access comes from the separate Git connection in Settings. --- # Agents and workflows > The AI agents that run in an AI CodeOps session and the 16 built-in workflows that order them, from Plan, Build, Review & Test to Incident Response. Source: https://aicodeops.dev/docs/agents A session isn't one AI model answering one prompt. It is a **workflow**: a fixed sequence of steps, each run by an **agent** with its own role and instructions. Planning, building, reviewing and testing are done by different agents, so the work is checked by something other than the thing that wrote it. ## The built-in agents | Agent | Role | | ------------------ | --------------------------------------- | | Architect | Plans, risks, staged execution. | | Builder | Implements approved changes. | | Reviewer | Correctness and maintainability review. | | Tester | Tests, typecheck and quality gates. | | Security Auditor | Security risks, secrets, CVEs. | | UI Designer | Visual and UX planning. | | DevOps Engineer | CI/CD, infrastructure, pipelines. | | Product Analyst | Requirements and acceptance criteria. | | Project Planner | Phased delivery plans. | | Researcher | Prior art and codebase survey. | | Backend Engineer | Server-side implementation. | | Frontend Engineer | Client-side implementation. | | E2E Tester | End-to-end test coverage. | | Dependency Auditor | Supply-chain audit. | | Database Engineer | Schema and migration design. | | Incident Responder | Incident triage. | | Site Reliability | SLOs, runbooks, postmortems. | | ADR Writer | Architecture decision records. | Some workflows also use a technical writer, a migration specialist and a performance tester. More about each agent is on the [agents page](https://aicodeops.dev/agents). ## The built-in workflows Pick a workflow in the **Workflow** list when you [start a session](https://aicodeops.dev/docs/sessions). **Develop → Workflows** shows the full catalog. | Workflow | Steps | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Plan, Build, Review & Test** (default) | Plan → Build → Review → Test | | **Quality-Gated Change** | Build → Test → Review | | **Security-Sensitive Change** | Scope change → Risk analysis → Implement → Audit diff → Validate | | **Parallel Review** | Correctness, security and test-coverage reviews, one after another, then findings merged | | **UI Implementation** | UI plan → Implement → Code review → Behavior test | | **DevOps Change** | DevOps plan → Risk review → Apply → Validate | | **Feature SDLC** | Requirements → Delivery plan → Technical design → Backend → Frontend → E2E tests → Security review → User docs | | **Discovery & Spec** | Prior art → Requirements → Delivery plan (no code) | | **Architecture Debate** | Two architects propose, a reviewer critiques, the architect synthesises | | **Threat Model** | Scope and data flow → STRIDE analysis → Record ADR | | **Swarm Inspection** | Review, security and test slices across the codebase, then a merged summary | | **Release Readiness** | Review, security, E2E sanity and dependency audit, then a go/no-go | | **Incident Response** | Triage → Root cause → Mitigation → Verify → Postmortem | | **Dependency Refresh** | Audit → Upgrade → Test → Security re-check | | **Performance Tuning** | Profile → Optimization plan → Apply → Re-measure | | **Data Migration** | Schema → Migration → Validate → Security → Final review | Architecture Debate, Discovery & Spec and Threat Model record an architecture decision record (ADR) you can find under **Plan → ADRs**. ## What happens after the agents finish Whatever the workflow, a session that writes code goes through the same checks: your project's tests run against the change, an AI review records findings, and a person approves it before a pull request opens. See [Quality gates](https://aicodeops.dev/docs/quality-gates). ## Models per step On the platform's models with **Auto**, each step gets the tier that suits it: steering steps (architect, reviewer, security auditor, researcher, planners) get the best tier you have allowance for, code-writing gets Standard, and drafting gets Economy. See [Models and tiers](https://aicodeops.dev/docs/models). ## Custom agents and skills Under **Configure → Agents**, choose **New agent** to define your own agent: its model, permissions and prompt. Under **Configure → Skills** you find reusable instructions agents can apply, such as Security Review, Test Generation, Refactor, Migration and Documentation. Policies can limit which agents and workflows run without approval. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Next steps - [Start a session](https://aicodeops.dev/docs/sessions) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [All agents](https://aicodeops.dev/agents) ## Frequently asked questions ### Which workflow should I start with? Plan, Build, Review & Test. It is the default and suits most code changes. Pick a specialised workflow when the task is clearly security, UI, infrastructure, data or incident work. ### Can I add my own agents? Yes, for the built-in roles. Under Configure → Agents you can give an agent your own prompt, model and permissions; it takes effect where a workflow step uses that agent. Workflows themselves can't be customised yet, so an agent for a brand-new role isn't run. --- # Models and tiers > Choose how AI CodeOps sessions get a model: the platform's Economy, Standard and Premium tiers or Auto within your plan's allowance, or your own provider key. Source: https://aicodeops.dev/docs/models Every session needs an AI model. There are two ways to get one: the platform's models, which come with your plan, or a key from your own model provider. ## The platform's models With no provider of your own, sessions run on the platform's models, organised in tiers: | Tier | What it is | | ------------ | -------------------------------------------- | | **Economy** | The default, included in every plan. | | **Standard** | Mid-grade models, for example Kimi or GLM. | | **Premium** | Top models, for example Claude. | | **Auto** | Picks the tier for each step of the session. | Which models sit behind each tier is set by the platform and can change as better models appear. A tier that isn't set up isn't offered. ### Auto Auto routes each step of a session to the tier that suits it: - Steps that steer the work (planning and architecture, review, security, research and requirements) use the best tier you have allowance for: Premium, then Standard, then Economy. - The code-writing step uses Standard first, then Premium, then Economy. - Bulk drafting steps use Economy first. That gets close to Premium quality while spending far fewer Premium tokens. When more than one tier is available, Auto is first in the list and is the default. ### Choosing a tier When you start a session under **Develop → AI Sessions → New session**, the **Model tier** list shows each tier with what's left, for example "2.1M tokens left this month". A tier your plan doesn't include shows "not in your plan"; one whose allowance is spent shows "used up this month". The list appears only when the workspace has no provider of its own and more than one tier is available. ## Allowances Each plan includes a monthly token allowance per tier (input plus output tokens). The current amounts are on the [pricing page](https://aicodeops.dev/pricing). Allowances: - are shared by every workspace owned by the same account; - start again on the 1st of each month (UTC); - are shown under **Measure → Usage** in **AI allowance this month**: a bar per tier, amber from 80%, red when used up. ### When an allowance runs out If the workspace has credits, the session continues on credits and the real cost is taken from them. Otherwise it stops and says what ran out. To keep going, you can: - start the session on another tier; - add credits on the **Billing** page; - connect your own provider key; - move to a plan with a larger allowance. ## Bring your own key Workspace admins can add provider keys on the workspace **Dashboard**, in **Bring Your Own Key**. Keys that can run sessions: - Anthropic (Claude) - OpenAI - Moonshot (Kimi) - Z.ai (GLM) - DeepSeek - Groq - OpenRouter - Ollama Cloud Google Gemini keys can be stored but can't run sessions. When a workspace has its own key, sessions run on it first. The launcher then shows a **Model** list (default "Provider default") instead of tiers. Keys are encrypted at rest and shown masked. Sessions on your own key are billed by that provider and don't use the platform allowance. Their cost still counts toward the workspace's [cost budget](https://aicodeops.dev/docs/cost-controls). ## Next steps - [Cost controls](https://aicodeops.dev/docs/cost-controls) - [Sessions](https://aicodeops.dev/docs/sessions) - [AI coding cost calculator](https://aicodeops.dev/tools/ai-coding-cost-calculator) ## Frequently asked questions ### Does my own provider key use the platform allowance? No. Sessions on your own key are billed by that provider and don't count against the allowance. They do count toward the workspace's cost budget. ### Will a session switch to a cheaper tier when Premium runs out? No. A session never drops to another tier by itself. Only Auto picks tiers, and only ones you still have allowance for. --- # Sessions > Start an AI session in AI CodeOps: describe the task, pick a project and workflow, watch the agents work live, review the diff, and open a pull request. Source: https://aicodeops.dev/docs/sessions A session is one piece of AI work on a project. You describe a task; a team of agents plans it, writes the change, reviews it and runs your tests. You then review the result and decide whether it ships. Everything runs on the platform; you watch it in the browser. ## Start a session 1. Open **Develop → AI Sessions** and choose **New session**. 2. Fill in the **Start an AI session** form (fields below). 3. Choose **Start session**. The session is queued and appears in the list. The form's fields: - **What should the session do?** Describe the task in plain words, for example "Add rate limiting to the public API and write tests for it." - **Workflow:** how the agents should work. The default, **Plan, Build, Review & Test**, suits most changes. See [Agents and workflows](https://aicodeops.dev/docs/agents). - **Project:** required. AI-generated code always belongs to a [project](https://aicodeops.dev/docs/projects). - **Model tier** or **Model:** which models to use. See [Models and tiers](https://aicodeops.dev/docs/models). - **File context (optional):** comma-separated paths the agents should read first. You can also start one from a project's page with **Run workflow**. ## Watch it live The session page updates as it runs. You see each step (which agent, what it is doing, its status), and the session's cost and tokens as they accrue. The list under **AI Sessions** shows every session with its project, duration, cost and status, and badges for sessions that produced changes or findings. To stop a session, choose **Cancel session** and give a reason. The reason is saved on the session and shown on its page. ## Review the result When the session finishes, its page shows: - **Summary:** what the agents did. - **Proposed changes:** the diff, with a `.patch` download. - **Quality gates:** test results and whether the change is release-ready. See [Quality gates](https://aicodeops.dev/docs/quality-gates). - **Findings:** issues the review found, with severity and file. Every session that writes code is also listed under **Develop → Changes**, where you can follow it from proposal through review, merge and deployment. ## Ask for changes Use the **Follow-up prompt** box on the session page to ask for refinements or a next task that builds on this one. Choose **Send follow-up**; it continues from the session's context. While a session is still running, a follow-up starts a new, linked session; the running one carries on unchanged. **Re-run** starts the same task again from the beginning. ## Approve and open a pull request A session that changes code opens a review on **Review & Gate → Approvals**. On the session page, choose **Accept changes** or **Reject**. The person who launched the session can't approve it if someone else in the workspace can. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). Once the change is approved and passes its quality gates, AI CodeOps opens the pull request for you: a new branch `codeops/run-` in the project's repository, into its default branch. You can also choose **Create Pull Request** yourself. The button explains what's missing if it's locked, for example **Connect git to open PR** or **Add a repository to open PR**. Nothing merges without your approval. ## Terminal **Develop → Terminal** (beta) opens a shell at a project's root in its own isolated sandbox, for when you want to look around or run a command yourself. Commands never run on the platform's own servers. Availability depends on your plan. ## Next steps - [Agents and workflows](https://aicodeops.dev/docs/agents) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [Cost controls](https://aicodeops.dev/docs/cost-controls) ## Frequently asked questions ### Do I need to install anything to run a session? No. Sessions run in the cloud and you follow them in the browser. There is no CLI or local setup. ### Can I change a session's result before approving it? You can ask for changes with a follow-up prompt. Editing the change after it was approved resets its approval, so it has to be approved again. --- # Workflows > The 16 built-in AI CodeOps workflows and their steps, plus how to start one, schedule it, re-run it, cancel it, and build on a finished session with follow-ups. Source: https://aicodeops.dev/docs/workflows · Last updated: 2026-10-18 A workflow is the recipe a session follows: a fixed list of steps, each run by one [agent](https://aicodeops.dev/docs/agents). You pick the workflow when you start a [session](https://aicodeops.dev/docs/sessions). Whichever you pick, a session that writes code ends the same way: your tests run, the AI review records findings, and a person approves before a pull request opens. ## The built-in workflows Browse them under **Develop → Workflows**, in the **Workflow Catalog**. ### Building and changing code | Workflow | Steps (agent) | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Plan, Build, Review & Test** (default) | Plan (Architect) → Build (Builder) → Review (Reviewer) → Test (Tester) | | **Quality-Gated Change** | Build (Builder) → Test (Tester) → Review (Reviewer) | | **Security-Sensitive Change** | Scope change (Architect) → Risk analysis (Security Auditor) → Implement (Builder) → Audit diff (Security Auditor) → Validate (Tester) | | **UI Implementation** | UI plan (UI Designer) → Implement (Builder) → Code review (Reviewer) → Behavior test (Tester) | | **DevOps Change** | DevOps plan (DevOps Engineer) → Risk review (Security Auditor) → Apply (DevOps Engineer) → Validate (Tester) | | **Feature SDLC** | Requirements (Product Analyst) → Delivery plan (Project Planner) → Technical design (Architect) → Backend → Frontend → E2E tests → Security review → User docs (Technical Writer) | ### Review and readiness | Workflow | Steps (agent) | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Parallel Review** | Correctness review (Reviewer) → Security review (Security Auditor) → Test coverage review (Tester) → Merge findings (Architect) | | **Swarm Inspection** | Reviewer slice → Security slice → Tester slice → Merge summary (Architect) | | **Release Readiness** | Correctness review → Security review → E2E sanity → Dependency audit → Go / no-go (Architect) | ### Discovery and design | Workflow | Steps (agent) | | ----------------------- | -------------------------------------------------------------------------------------------- | | **Architecture Debate** | Architect A → Architect B → Critic review (Reviewer) → Final synthesis (Architect) | | **Discovery & Spec** | Prior art (Researcher) → Requirements (Product Analyst) → Delivery plan (Project Planner) | | **Threat Model** | Scope & data-flow (Architect) → STRIDE analysis (Security Auditor) → Record ADR (ADR Writer) | These three save their decision as a proposed architecture decision record under **Plan → ADRs**. ### Operations and maintenance | Workflow | Steps (agent) | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Incident Response** | Triage (Incident Responder) → Root cause (Architect) → Mitigation (Builder) → Verify (Tester) → Postmortem (Site Reliability) | | **Dependency Refresh** | Audit (Dependency Auditor) → Upgrade (Migration Specialist) → Test (Tester) → Verify secure (Security Auditor) | | **Performance Tuning** | Profile (Performance Tester) → Optimization plan (Architect) → Apply (Builder) → Re-measure (Performance Tester) | | **Data Migration** | Schema (Database Engineer) → Migration (Migration Specialist) → Validate (Tester) → Security → Final review (Reviewer) | Steps always run one after another, and each step sees what the earlier steps wrote. The catalog's **Parallel**, **Debate** and **Swarm** labels describe how the steps divide the work, not that they run at the same time. A step whose name contains "plan" also adds its items to the **Plan board**. ## Start a workflow You can start one from several places: - **Develop → AI Sessions → New session.** Pick any workflow in the **Workflow** list. The default is **Plan, Build, Review & Test**. - **Develop → Workflows.** Choose **Launch** on a workflow, describe the task, pick a **Project**, and choose **Start session**. - **A project's page.** **Run workflow** starts the default workflow on that project. - **Fix with AI**, on an incident, the **Quality** page or the **Security** page, and **Fix** on a finding. These start the default workflow on the problem. - **A schedule** (below). Every workflow run needs a project. Your workspace policy can require approval to start a workflow, or deny it. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Schedule a workflow Open **Release → Schedules** and choose **New schedule**. 1. Enter a **Name**, pick a **Workflow** and a **Project**. 2. Enter a 5-field **Cron expression** and a **Timezone**. Choose **Preview next 5** to check the times. 3. Optionally describe the **Task**. Without one, the session runs "Run the scheduled workflow" with the schedule's name. 4. Choose what happens if a scheduled tick is missed: catch up once, skip missed, or exact. 5. Choose **Create schedule**. Each schedule row has **Run now**, **History**, **Edit**, **Clone**, **Disable** and **Delete**. Deleted schedules can be restored from **Recently deleted**. ## Cancel a session On a running session's page, choose **Cancel session**. Enter a reason, then confirm **Cancel session**. The session stops within a few seconds, including any model call in flight, and its change is marked abandoned. You need a role that can manage sessions; viewers can't cancel. ## Re-run a session On a finished session's page, choose **Re-run** and confirm. It starts a new session with the same task, workflow, project and model. The new session isn't linked to the original. If the original workflow can't be launched any more, the re-run uses the default workflow and the dialog says so. ## Follow up on a session A follow-up builds on an earlier session instead of starting over. 1. On the session page, write in the **Follow-up prompt** box, for example "Also handle the empty-input case." 2. Pick the workflow for the follow-up. It defaults to the same one. 3. Choose **Send follow-up**. The follow-up is a new session, linked to its parent: its page shows **Parent session** under Linkage. It uses the parent's project and model, and gets the parent's task and summary as context. If the parent's change hasn't been merged yet, the follow-up starts from it, so the new diff contains both. While a session is still running, the same box says **Mid-session handoff / follow-up** and the button **Spawn handoff**. It starts a new linked session. The running session carries on. Choosing a step in the session's step strip starts the new session from that step. ## Next steps - [Multi-agent reviews](https://aicodeops.dev/docs/multi-agent-reviews) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [All agents](https://aicodeops.dev/agents) ## Frequently asked questions ### Can I build my own workflow? Not yet. Every session runs one of the 16 built-in workflows, each with a fixed list of steps. ### Do the steps of Parallel Review run at the same time? No. Every workflow runs its steps one after another. Parallel, debate and swarm describe how the steps divide the work, not timing. ### Is Re-run the same as a follow-up? No. Re-run starts the same task again from scratch, with no link to the original. A follow-up builds on the earlier session and is linked to it. --- # Quality gates > How AI CodeOps decides whether a change can ship: test results, the AI findings review, approvals, and the release gate check your CI can call. Source: https://aicodeops.dev/docs/quality-gates Every AI session ends with a change: a diff against your project's repository. Before that change can become a pull request, AI CodeOps checks it. The checks are the same whether you open the pull request from the console or ask from your CI. ## What the gate checks A change is **release-ready** when all of these hold: - **Tests pass.** After writing the change, the session runs your project's test command in its sandbox and records the result. Failing tests block the change. - **The AI findings review completed.** A reviewer step reads the diff and records findings (security, quality, performance, reliability, test coverage and other categories). If that review could not finish, for example because the model failed, the findings are unknown and the change is held: "The automated review of this change didn't complete, so its findings are unknown. Re-run the session". - **No blocking findings are open.** Findings of severity **high** or **critical** block until they are triaged. - **Tests count for the version they ran on.** If someone edits the change after its tests ran, the old result neither passes nor blocks it: the gate says this version is untested and the approval opens again, so a person decides before it ships. Re-run the session to test the new version. Approvals are a separate check on the same path. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Where you see it Open a session's run page. The **Quality gates** panel shows **Release-ready** or **Gate checks pending**, the test totals, each test result, and the reasons the change is not ready yet. The **Findings** panel lists each finding with its severity, file and line. Workspace-wide test results and open findings are under **Build & Test → Quality**. ## Triage findings Each finding has a status. Change it from the dropdown on the run's Findings list: | Status | Blocks the change? | | ------------------------------------------- | ------------------------ | | open, acknowledged, in progress | Yes, if high or critical | | fixed, won't fix, false positive, duplicate | No | You can also choose **Fix** on a finding to launch an AI run that fixes it. Changing a finding's status needs a role with triage permission. Owners, admins, developers, members and security admins have it; viewers don't. ## What the gate blocks When you choose to open a pull request, AI CodeOps checks in this order: 1. The workspace policy. A deny rule stops the pull request; an ask rule needs an approved review. 2. The approval. A rejected or pending approval stops it. 3. The quality gate. A change that isn't release-ready gets the first reasons, for example "This change isn't release-ready: HIGH security: …". The same quality gate runs again before the console merges a pull request it opened. The pull request opens on a branch named `codeops/run-`. ## The release gate for CI **Review & Gate → Release gate** evaluates a pull request URL or commit SHA across every session that touched it, and shows **Allowed** or **Denied** with reasons. Your CI can ask the same question through `POST /api/release/check` with a workspace API key. The CI check adds options the per-run gate doesn't use: required workflows, a minimum coverage percentage, disallowed licenses (checked against the project's SBOM), and a required prior deployment such as staging. The fields and response are on the [API page](https://aicodeops.dev/docs/api). If the gate check itself can't run, for example during a brief outage, the pull request is not opened: "The release check couldn't run just now." Try again in a moment. ## Next steps - [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies) - [Security and SBOM](https://aicodeops.dev/docs/security-and-sbom) - [Evidence packs](https://aicodeops.dev/docs/evidence-packs) ## Frequently asked questions ### Can I open a pull request while findings are still open? Not while a high or critical finding is open, tests are failing, or the AI review didn't finish. Triage the finding or re-run the session, then open the pull request. ### What if my project has no tests? If the session couldn't run tests, nothing is recorded and no test result blocks the change. The run page shows that verification was skipped. --- # Approvals and policies > Set what AI sessions may do with workspace policy rules (allow, ask, deny) and how human approvals work: who can approve, expiry, and rejections. Source: https://aicodeops.dev/docs/approvals-and-policies Policies decide what an AI session may do on its own and what needs a person. Approvals are where that person says yes or no. Both are recorded in the audit log and in the change's [evidence pack](https://aicodeops.dev/docs/evidence-packs). ## Workspace policy Open **Secure → Policies**. The page shows whether the policy is **Enforced** or **Log only**, the trust posture, the rules in effect, the version, and recent decisions. Owners, admins and security admins can edit it (the policy-manage permission). ### Trust posture The posture applies when no rule matches. Whatever the posture, a session's code change still needs an approved review before its pull request opens (see Approvals below). | Posture | What it means | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Trusted | Everything a rule does not restrict is allowed. | | Limited (default) | As trusted, but opening a pull request is an ask: it needs an approved review first. | | None | Sessions can still write a proposed change, but can't call MCP tools, run the test command, open a pull request or deploy unless a rule allows it. | ### Rules Each rule has an action, a decision (**allow**, **ask** or **deny**) and an optional resource pattern. The strictest matching rule wins: deny beats ask, ask beats allow. | Action | Label | Resource | Can ask? | | ------------------- | -------------------- | --------------------- | -------- | | `workflow.dispatch` | Start a session | workflow | Yes | | `agent.dispatch` | Run an agent step | agent | Yes | | `diff.apply` | Change a file | path, e.g. `infra/**` | Yes | | `github.push` | Open a pull request | owner/repo | Yes | | `mcp.invoke` | Call an MCP tool | server/tool | No | | `shell.command` | Run the test command | command | No | | `release.deploy` | Deploy automatically | environment | No | Protected paths are `diff.apply` rules with a file pattern. They are checked when a pull request is opened, against every file the change touches; the session still writes the change. Automatic deploys after a merge are `release.deploy` rules. An action that can't wait for a person can't use ask; the editor refuses it. Choose **Edit rules** to change the posture and the rules, then save. Each save creates a new version and an audit entry. **Switch to log only** keeps evaluating rules and records what they would have done, without blocking anything. That is useful while you tune a new policy. ## Approvals An approval request is opened for you when: - a session produces a code change (every change needs review, whatever the posture); - a session start hits an ask rule (the session waits as held until the request is decided); - a pull request is requested for a change that needs review and has none yet. Open **Review & Gate → Approvals**. **Pending requests** lists each request with how many approvals it needs and when it expires. Choose **Review the proposed changes** to see the diff, then **Approve** (an optional note) or **Reject** (a reason is required). The run page has the same decision as **Accept changes** and **Reject**. ### Who can approve Owners, admins and security admins can approve by default; a custom role can be given the permission too. A request can also name specific approvers. The person who launched a session can't approve its change when anyone else in the workspace can. A solo team can still approve its own work. Rejecting is always allowed. ### Rules of the decision - A code-change review needs one approval, from someone other than the person who launched the session (when the team has someone else who can approve). That makes it a two-person rule. Approvals are counted per distinct person, and voting again replaces your earlier vote. - A single reject ends the request as rejected. It is not reopened by someone else approving. - Code-change reviews expire after 7 days; a held session start expires after 3 days. After expiry, use **Request approval again** on the run page. - Editing a change after it was approved resets its approval to pending. - Approving a code change opens its pull request, if the [quality gate](https://aicodeops.dev/docs/quality-gates) also passes. ## Next steps - [Members and roles](https://aicodeops.dev/docs/members) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [Audit and RBAC](https://aicodeops.dev/product/audit-rbac) ## Frequently asked questions ### Can I approve a change from a session I started? Not if someone else in the workspace can approve. Self-approval is only allowed on a team with no other approver. ### What happens when an approval expires? The change stays blocked. On the run page you can choose Request approval again to open a new review. --- # Multi-agent reviews > How AI CodeOps reviews a change with several agents: review steps, a findings pass over the real diff, severity and triage, and the human approval that follows. Source: https://aicodeops.dev/docs/multi-agent-reviews · Last updated: 2026-10-18 In AI CodeOps, the agent that writes a change isn't the one that checks it. Review steps in the workflow look at the work from different angles. A findings pass then reviews the actual diff and records structured findings. A person makes the final call. ## Review steps in the workflow Most [workflows](https://aicodeops.dev/docs/workflows) include one or more review steps, each run by its own agent: - **Plan, Build, Review & Test** has a Review step by the [Reviewer](https://aicodeops.dev/agents/reviewer). - **Security-Sensitive Change** has a Risk analysis before the change and an Audit diff after it, both by the [Security Auditor](https://aicodeops.dev/agents/security-auditor). - **Parallel Review** has three reviews (correctness by the Reviewer, security by the Security Auditor, test coverage by the [Tester](https://aicodeops.dev/agents/tester)), then a Merge findings step that combines them. - **Release Readiness** adds an E2E sanity check and a dependency audit, then a Go / no-go step. - **Architecture Debate** has two architects each propose an approach, a critic review them, and a final synthesis. The steps run one after another. Each sees what the earlier steps wrote, so a merge or synthesis step works from every review before it. Nothing is decided by vote. ## The findings pass Workflow steps run before the code exists: they plan and discuss the change. So after the change is written and tested, AI CodeOps runs a separate review of the diff itself. It gets: - the diff, as the thing to review; - the notes from every step whose name mentions review, security, audit, risk or test, as context. It records up to 12 concrete issues as findings. They're credited to the Security Auditor if that agent ran in the session, otherwise to the Reviewer, otherwise to the last agent that ran. Each finding has a title, a description, a recommendation and, usually, a file. ### Severity | Severity | Blocks the change while unresolved? | | -------- | ----------------------------------- | | critical | Yes | | high | Yes | | medium | No | | low | No | | info | No | ### Category Security, quality, performance, accessibility, compliance, dependency, documentation, test coverage, reliability, cost, UX or other. ### When the review can't finish The findings pass has two minutes. If the model fails, runs out of time, the budget runs out first, or the reply can't be read, the review counts as not completed. The change is then held with "The automated review of this change didn't complete, so its findings are unknown. Re-run the session". An empty list, by contrast, is a completed review with nothing found. ## Triage findings Open a session's page and find the **Findings** list. Set each finding's status from its dropdown: | Status | Still blocks (if high or critical)? | | ------------------------------------------- | ----------------------------------- | | open, acknowledged, in progress | Yes | | fixed, won't fix, false positive, duplicate | No | Choose **Fix** on a finding to start a session that fixes it. Workspace-wide findings are under **Build & Test → Quality**. Changing a status needs a role with triage permission; viewers don't have it. See [Quality gates](https://aicodeops.dev/docs/quality-gates). ## The human review When the findings pass is done and the session produced a diff, AI CodeOps opens a review request on **Review & Gate → Approvals**. A person reads the diff and the findings, then approves or rejects. - The person who started the session can't approve it while someone else in the workspace can. A one-person workspace can approve its own change. - One rejection ends the request. - Editing the change after approval sends it back for approval. Approving opens the pull request, if the quality gate also passes. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Next steps - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [How AI CodeOps works](https://aicodeops.dev/docs/how-it-works) - [AI code review](https://aicodeops.dev/product/review) ## Frequently asked questions ### Does the review look at the code or at the plan? The code. The findings pass reads the actual diff the session produced. The review steps' notes are given to it as context. ### Do the reviewing agents vote? No. Each review step writes its analysis in turn, and a final step or the findings pass reads them all. There is no voting or consensus count. ### What happens if the AI review fails? The change is held. Its findings are unknown, so it can't open a pull request until you re-run the session. --- # Security and SBOM > How AI CodeOps handles security findings, SBOMs per project (CycloneDX and SPDX), license checks in the release gate, sandboxed terminals and encrypted secrets. Source: https://aicodeops.dev/docs/security-and-sbom AI CodeOps looks for security problems in every change it writes, keeps track of what each project ships through its software bill of materials (SBOM), and records who did what. This page covers the parts you work with as an administrator. ## Security findings Every session ends with an AI review of its diff. Findings in the **security** category, like any finding, carry a severity (critical, high, medium, low, info), the file and line, and a triage status. Open high and critical findings block the change until they are triaged; see [Quality gates](https://aicodeops.dev/docs/quality-gates). Workflows built for security work go further. **Security-Sensitive Change** runs a risk analysis before the change is written and audits the diff after. **Threat Model** produces a STRIDE analysis and records it as an architecture decision record. See [Agents and workflows](https://aicodeops.dev/docs/agents). **Secure → Security** shows the workspace's security posture: a score, counts by severity, and a table of open security findings: severity, the file (under **Package**), description and the reviewer's recommended fix. The **CVE** column shows a dash, because there is no CVE scanner. **Fix with AI** starts a session to fix a finding. As with any session, you review and approve the change before a pull request is opened. ## SBOMs per project An SBOM lists the components a project ships, with their versions and licenses. AI CodeOps tracks SBOMs per project in **CycloneDX** or **SPDX** format. Each SBOM record holds the format and version, the number of components and of vulnerable components, a license summary, the commit it describes, a SHA-256 hash, and a link to the SBOM file. AI CodeOps doesn't generate SBOMs: create yours with the tool you already use in your build. Where you see them: - **Secure → Security**, panel **Software Bill of Materials**: projects with SBOMs, distinct licenses, and a license roll-up across projects. - A project's page: **Recent SBOMs** and **Vulnerable components (latest SBOM)**. In the open beta there is no upload form. A snapshot is recorded with a request to `/api/sbom` from a signed-in session; recording one from CI with an API key is not available yet. To look inside an SBOM file without signing in, try the [SBOM viewer](https://aicodeops.dev/tools/sbom-viewer). ## License checks The release gate your CI calls can deny a change when the project's latest SBOM contains a license you've disallowed, such as `GPL-3.0` or `AGPL-3.0`. A project with no SBOM can't be checked, so the gate denies it too when a license rule is set. The options are on the [API page](https://aicodeops.dev/docs/api). ## Sandboxed execution Sessions run on the platform, not on your machine. When a session runs your tests, it runs them in an isolated environment for the project. **Develop → Terminal** (beta) opens a shell at your project's root in its own isolated sandbox: a container on the platform, never the platform's own servers. Opening a terminal needs a role that can manage projects, and availability depends on your plan. ## Secrets and keys - Git tokens, model provider keys and workspace secrets are encrypted at rest with AES-256-GCM. - API keys are stored only as a hash and shown once, when created. - Workspace secrets are managed in **Configure → Settings**; the Secret Manager role can manage secrets without any other access. ## Audit log **Measure → Audit Log** records what changed in the workspace and who changed it: members and roles, keys, providers, policies, agents, schedules, budgets, secrets, approvals and generated code. Each entry has the time, account, target and IP address. Owners, admins and security admins can read it. How long entries are kept depends on your plan. ## Next steps - [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies) - [Members and roles](https://aicodeops.dev/docs/members) - [Evidence packs](https://aicodeops.dev/docs/evidence-packs) ## Frequently asked questions ### Does AI CodeOps generate SBOMs for me? No. You generate the SBOM with your usual tool and record it against the project. AI CodeOps tracks it and uses it for license checks. ### Where are security findings shown? On the run page of the session that found them, and across the workspace under Secure → Security. --- # Dependency audit > Run the Dependency Auditor agent on your project, see what it reads and reports, and how its findings land in the review that gates the pull request. Source: https://aicodeops.dev/docs/dependency-audit · Last updated: 2026-10-18 The [Dependency Auditor](https://aicodeops.dev/agents/dependency-auditor) is an AI agent that checks a project's dependencies. It looks for packages with known vulnerabilities (CVEs), license problems and packages that look unmaintained, and suggests an upgrade path for each. Its report then feeds the review that decides whether the change can ship. ## Where it runs The agent is a step in two built-in workflows: | Workflow | Step | What the workflow does | | ------------------ | ---------------- | --------------------------------------------------------------------------- | | Dependency Refresh | Audit | Audit, then upgrade, test and re-check security. 4 steps. | | Release Readiness | Dependency audit | Correctness review, security review, E2E sanity, dependency audit, go/no-go | In Dependency Refresh the audit goes first. The [Migration Specialist](https://aicodeops.dev/agents/migration-specialist) plans the upgrade from its list, the Tester plans how to prove nothing broke, and the [Security Auditor](https://aicodeops.dev/agents/security-auditor) checks the result. In Release Readiness the audit sees the three checks before it, and the Architect's go/no-go reads all of them. ## Run a dependency audit 1. Open **Develop → AI Sessions** and choose **New session**. 2. Describe the task, for example "Audit and upgrade our dependencies before the Q4 release." 3. Choose the **Dependency Refresh** workflow and your project. 4. Choose **Start session**. To run it regularly, schedule the same workflow under **Release → Schedules**. ## What the agent reads The agent works from a read-only snapshot of your repository, picked for the task: - Two places are reserved for orientation files: the README and a manifest (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml` or `pom.xml`). - Other files are chosen by how well they match the task, up to 16 files and about 32 KB in total. - Files larger than 48 KB are skipped, and each file is cut at 12 KB. - Lockfiles such as `yarn.lock`, `Cargo.lock`, `poetry.lock` and `go.sum` are not included, and a large `package-lock.json` is skipped by size. So the agent sees your direct dependencies, not the full transitive tree. It can also call tools from [remote MCP servers](https://aicodeops.dev/docs/mcp-servers) you connect, if your [workspace policy](https://aicodeops.dev/docs/policy-engine) allows them. It has no other tools: it doesn't run a package manager or query an advisory database. ## What it reports The step writes an audit grouped by problem: - packages with known vulnerabilities, the affected versions and the first fixed version; - licenses that may conflict with how the project is distributed; - packages that look abandoned, with maintained alternatives; - for each, an upgrade path and how risky it is, such as a patch release versus a new major version. You can read the full step output on the session's run page. ## How findings reach the gate The agent doesn't file findings directly. At the end of every session, an AI review reads the change's diff, with the output of the review, security, audit and test steps as context. That includes the dependency audit. The review records each concrete issue as a finding with: - a **severity**: critical, high, medium, low or info; - a **category**, such as `dependency`, `security` or `compliance`; - a title, a description and a recommendation. Because both workflows include the Security Auditor, these findings show the Security Auditor as their source. Open findings of severity **high** or **critical** block the pull request until someone triages them. The statuses that still block are open, acknowledged and in progress. See [Quality gates](https://aicodeops.dev/docs/quality-gates) for the full rules and how to triage. Dependency findings appear in the **Findings** panel of the session's run page. The workspace-wide **Secure → Security** list shows only the `security` category, so dependency findings don't appear there. ## Limits - The agent's vulnerability knowledge comes from the model and can be out of date. Confirm critical items with your scanner. - It sees only the files in the snapshot. Transitive dependencies are mostly invisible to it. - Its license notes are not legal advice. - SBOMs are tracked separately; AI CodeOps doesn't generate them. See [Security and SBOM](https://aicodeops.dev/docs/security-and-sbom). ## Next steps - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [Policy rules reference](https://aicodeops.dev/docs/policy-engine) - [DevSecOps and SBOMs](https://aicodeops.dev/product/secure) ## Frequently asked questions ### Does the dependency audit query a vulnerability database? No. The agent reads your manifests and uses the model's knowledge, which has a training cut-off. A remote MCP server you connect can give it live data. ### Can I run a dependency audit on a schedule? Yes. Schedule the Dependency Refresh workflow under Release → Schedules, like any other workflow. ### Where do I see dependency findings? On the session's run page, in the Findings panel. They block the pull request like any other high or critical finding. --- # Policy rules reference > Write workspace policy rules for AI sessions: the seven actions, allow, ask and deny, resource globs, trust postures, log-only mode, and a worked example. Source: https://aicodeops.dev/docs/policy-engine · Last updated: 2026-10-18 A workspace policy decides what AI sessions may do on their own, what needs a person's approval, and what they may never do. This page is the reference for writing rules. For how approvals work once a rule asks for one, see [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). Policies govern sessions only. What a person may do is set by their [role](https://aicodeops.dev/docs/roles-and-permissions). ## Open the policy Open **Secure → Policies**. The page shows: - **Enforcement**: **Enforced** or **Log only**. - **Rules in effect**, **Trust posture** and **Version**. - **Rules**: each rule's ID, action, resource and decision. - **How rules apply**: the actions and what each one matches. - **Recent decisions**: the latest denials, holds and log-only outcomes, with **View session**. The page is shown to roles with the policy-manage permission: owners, admins and security admins by default. ## Rule format Rules are a JSON array. Each rule has these fields: | Field | Required | What it is | | ------------- | -------- | ------------------------------------------------------------------ | | `id` | Yes | 1–64 characters: letters, digits, `.`, `_`, `:` or `-`. Unique. | | `action` | Yes | One of the actions below, or `*` for every action. | | `decision` | Yes | `allow`, `ask` (needs an approval) or `deny`. | | `resource` | No | A glob matched against what the action touches. Omitted means all. | | `description` | No | Up to 500 characters, shown under the rule's ID. | | `enabled` | No | `false` keeps the rule but stops it applying. | A policy can hold up to 200 rules. ## Actions | Action | Label | Resource it matches | When it is checked | Decisions | | ------------------- | -------------------- | -------------------------- | -------------------------------------------------- | ---------------- | | `workflow.dispatch` | Start a session | workflow ID | When a session starts | allow, ask, deny | | `agent.dispatch` | Run an agent step | agent ID, e.g. `builder` | When a session starts, for every agent it will run | allow, ask, deny | | `mcp.invoke` | Call an MCP tool | `server/tool` | When a session starts, for each connected MCP tool | allow, deny | | `shell.command` | Run the test command | the command | Before the session runs your tests | allow, deny | | `diff.apply` | Change a file | file path, e.g. `infra/**` | When the pull request is opened, for every file | allow, ask, deny | | `github.push` | Open a pull request | `owner/repo` | When the pull request is opened | allow, ask, deny | | `release.deploy` | Deploy automatically | environment name | Before an automatic deploy after a merge | allow, deny | Some actions can't wait for a person, so they can't use `ask`. The editor refuses an `ask` on them. A stored `ask` on one of them is enforced as `deny`. What each decision does: - **Session start** (`workflow.dispatch`, `agent.dispatch`): `deny` refuses the session. `ask` holds it until someone approves it under **Review & Gate → Approvals**; rejecting or letting it expire cancels it. - **MCP tools**: a tool that isn't allowed is never offered to the agents. - **Pull request** (`github.push`, `diff.apply`): `deny` refuses the pull request. `ask` requires an approved review of the change. The session still runs and proposes its change; the rule decides whether it can land. - **Automatic deploy**: anything but `allow` stops the deploy. It is recorded as a blocked deployment so you can see it didn't go out. ## How rules are evaluated 1. Every enabled rule whose `action` matches (or is `*`) and whose `resource` matches is considered. 2. The strictest decision wins: `deny` beats `ask`, and `ask` beats `allow`. Rule order doesn't matter. 3. If no rule matches, the trust posture decides. ### Resource globs - `**` matches anything, including `/`. - `*` matches any run of characters. For file paths, `server/tool` and `owner/repo`, it stops at `/`. - `?` matches one character. - No `resource`, `*` or `**` matches everything. So `src/*.ts` matches `src/app.ts` but not `src/lib/app.ts`; use `src/**` for the whole folder. ## Trust posture The posture applies when no rule matches. | Posture | Default decisions | | ------------------- | ---------------------------------------------------------------------------------------------------------- | | `trusted` | Everything is allowed. | | `limited` (default) | As trusted, but opening a pull request is `ask`. | | `none` | `deny` for MCP tools, the test command, file changes, pull requests and automatic deploys, unless allowed. | Every session that changes code also gets a review request under **Review & Gate → Approvals**. The posture adds to that; it doesn't remove it. ## Example This policy holds dependency upgrades for approval, asks for a review of any change to infrastructure files, blocks automatic deploys to production and keeps one MCP tool away from the agents: ```json [ { "id": "approve-dependency-refresh", "action": "workflow.dispatch", "resource": "dependency-refresh", "decision": "ask", "description": "A person approves before a dependency upgrade session starts" }, { "id": "review-infra-changes", "action": "diff.apply", "resource": "infra/**", "decision": "ask" }, { "id": "no-production-deploys", "action": "release.deploy", "resource": "production", "decision": "deny" }, { "id": "no-repo-deletes", "action": "mcp.invoke", "resource": "github/delete_*", "decision": "deny" } ] ``` ## Edit the policy 1. Open **Secure → Policies** and choose **Edit rules**. 2. Pick a **Trust posture**. 3. Edit the rules in the JSON box. An example is shown under it. 4. Choose **Save (version → N)**. If a rule has a problem, nothing is saved and every problem is listed, for example `Rule 2: decision — "mcp.invoke" cannot wait for an approval; use allow or deny`. If someone else saved first, you see "Policy conflict" and the page loads their version; make your change again. Each save creates a new version and a `policy.updated` entry in the [audit log](https://aicodeops.dev/docs/audit-logs). ## Log-only mode Choose **Switch to log only** to stop enforcing without deleting rules. Every decision is still computed and recorded, shown as "logged" under **Recent decisions**, but nothing is blocked or held. Choose **Enforce** to turn it back on. Use log-only mode while you tune a new policy. Only decisions other than a plain allow are recorded. ## Next steps - [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies) - [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions) - [MCP servers](https://aicodeops.dev/docs/mcp-servers) ## Frequently asked questions ### Does the order of my rules matter? No. Every matching rule is considered and the strictest decision wins, so adding a rule can never loosen an earlier one. ### Do policies limit what people can do? No. Policies govern what AI sessions may do. What a person may do is set by their role. ### Can I test a policy without blocking anyone? Yes. Choose Switch to log only. Rules are still evaluated and every decision is recorded, but nothing is blocked or held. --- # Evidence packs > Download a signed record of how one change was made (task, models, approvals, findings, tests, delivery) and verify it in the browser or offline. Source: https://aicodeops.dev/docs/evidence-packs An evidence pack is a signed record of how one change was made in AI CodeOps. It is for auditors, compliance reviews and customers who need to show how AI-written code reached production. ## What a pack contains For one change (**Develop → Changes**, then a change): - **The task:** the prompt given to the AI, the model, provider and tier, and the context files. - **The runs:** the session and every follow-up run, with status, timings, tokens and cost, plus each agent step's provider and model. - **The result:** the summary, the changed files and a SHA-256 hash of the diff. The code itself is not included; the hash lets you match it against the pull request. - **Approvals:** each approval request, who could approve, and every vote with its time and note. - **Policy decisions:** each allow, deny or ask the workspace's policies made during the change. - **Findings and tests:** review findings with their triage, and test results (passed, failed, skipped, coverage). - **Delivery:** the pull request, the deployment, and any incident linked to the change. - **The audit trail:** the audit log entries about any of the above. - **People:** the email address behind every account ID in the pack. ## Download a pack Open **Changes**, choose a change, and select **Download evidence pack**. You need audit access in the workspace: owners, admins and security admins have it. Every download is recorded in the workspace audit log. ## Verify a pack in the browser Open [/evidence/verify](https://aicodeops.dev/evidence/verify) and choose the file. No account is needed. The page tells you whether the signature matches and which key signed it. ## Verify a pack offline You don't have to trust our verifier. The pack's `signature` is Ed25519 over the canonical JSON of its `payload`: object keys sorted at every level, no whitespace. The platform's public keys are at `/api/evidence?action=keys`. With Node.js 20 or later: ```js // verify-evidence.mjs import { readFileSync } from "node:fs" import { createPublicKey, verify } from "node:crypto" const canonical = (v) => v === null || typeof v !== "object" ? JSON.stringify(v) : Array.isArray(v) ? `[${v.map(canonical).join(",")}]` : `{${Object.keys(v) .sort() .map((k) => `${JSON.stringify(k)}:${canonical(v[k])}`) .join(",")}}` const pack = JSON.parse(readFileSync(process.argv[2], "utf8")) const { keys } = JSON.parse(readFileSync(process.argv[3], "utf8")) const key = keys.find((k) => k.kid === pack.signature.kid) if (!key) throw new Error(`unknown key ${pack.signature.kid}`) const ok = verify( null, Buffer.from(canonical(pack.payload)), createPublicKey(key.publicKey), Buffer.from(pack.signature.value, "base64url"), ) console.log(ok ? "VERIFIED" : "NOT VERIFIED: the pack was altered") ``` Save the keys once, then run the script: ```bash curl -o keys.json "https://console.aicodeops.dev/api/evidence?action=keys" node verify-evidence.mjs evidence-chg_....json keys.json ``` ## Keys and rotation Keys are never deleted. When a key is retired it stops signing new packs, and the packs it signed still verify. Keep a copy of `keys.json` with your audit records if you want verification that doesn't depend on reaching the platform. ## Next steps - [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [API](https://aicodeops.dev/docs/api) ## Frequently asked questions ### Does the pack contain our source code? No. It lists the changed files and a SHA-256 hash of the diff, so you can match it against the pull request without the code leaving your repository. ### Do old packs still verify after a key is retired? Yes. Keys are never deleted. A retired key stops signing new packs, and the packs it signed still verify. --- # Gated deploys > How AI CodeOps hands a merged change to your deploy pipeline: the quality gate before merge, deploy webhooks, policy rules per environment and deploy records. Source: https://aicodeops.dev/docs/gated-deploys · Last updated: 2026-10-18 AI CodeOps doesn't deploy code to your infrastructure. It gates the change before it merges, calls your deploy pipeline when it does, and keeps a record of every deployment. Your own pipeline does the build and the release. ## The path to a deploy 1. A session's change passes its tests and AI review, and a person approves it. See [Quality gates](https://aicodeops.dev/docs/quality-gates). 2. AI CodeOps opens the pull request. 3. You merge it from the console. The quality gate runs again first: open high or critical findings, failing tests, or an unfinished review stop the merge. 4. If the change's project has a deploy target, AI CodeOps calls its webhook and records a deployment. Merging needs a role that can manage deployments: owners, admins, developers, members and DevOps admins. If the gate check can't run, the merge doesn't happen: "The release check couldn't run just now. Try again in a moment." The gate on merge applies to pull requests AI CodeOps opened for a session. A pull request someone wrote by hand has no session, so the gate has no findings or tests to judge it on. ## Set a deploy target 1. Open **Release → Deployments** and choose **Deploy targets**. 2. For each project, enter the **Deploy webhook URL**. It must be a public `https://` address. 3. Enter the **Environment** it deploys to. The default is `production`. 4. Optionally enter a **Signing secret**. 5. Choose **Save**. Leave the URL blank to turn automatic deploys off for that project. Setting deploy targets needs a role that can manage projects. ### What your webhook receives When a change merges from the console, AI CodeOps sends a `POST` with this body: ```json { "event": "pr_merged", "workspaceID": "wrk_…", "projectID": "billing-api", "repo": "acme/billing-api", "prNumber": 42, "prUrl": "https://github.com/acme/billing-api/pull/42" } ``` With a signing secret, the request carries `X-CodeOps-Signature: sha256=`: an HMAC-SHA256 of the raw body, keyed with your secret. Check it before you deploy. The call times out after 10 seconds and doesn't follow redirects. A `2xx` answer records the deployment as **in progress**. Anything else records it as **failed**, with "The deploy webhook answered HTTP …", and opens an incident. Choose **Retry delivery** on the row to send it again; each retry is a new record. Your pipeline can't report the final result back to AI CodeOps, so a deploy sent by webhook stays **in progress** in the history. To log a finished deploy with its outcome, record it by hand (below). ## Allow or deny automatic deploys Automatic deploys follow your workspace policy's `release.deploy` rules, matched on the environment name. For example, this rule stops automatic deploys to production: ```json { "id": "no-production-deploys", "action": "release.deploy", "resource": "production", "decision": "deny" } ``` A denied deploy is never sent. It's recorded as **canceled**, and the row shows "not deployed" with the reason. If the policy can't be loaded, the deploy is canceled the same way. These rules can allow or deny only; they can't wait for an approval. A person choosing **Retry delivery** is governed by their role, not by these rules. See [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ## Record a deployment by hand For deploys that happen outside AI CodeOps: 1. Open **Release → Deployments** and choose **Record deployment**. 2. Pick the **Project** and enter the **Environment**. 3. Set the **Status**: succeeded, in progress, queued or failed. 4. Optionally add a **Version** and a **Commit SHA** (at least 7 characters). 5. Choose **Record deployment**. ## Deployment records Each record has the project, environment and a sequence number per environment, the commit or version, the status, start and end times, and the session that produced the change. Statuses are queued, in progress, succeeded, failed, rolled back and canceled. A deployment that succeeds for a session's change marks the change **deployed** under **Develop → Changes**. Records feed the delivery metrics on the dashboard, and the change's [evidence pack](https://aicodeops.dev/docs/evidence-packs). ## Check a release from CI Your pipeline can ask the release gate before it deploys. Call `POST /api/release/check` with a workspace API key, the pull request URL or commit SHA, and options such as `requireDeployedTo`. With `"requireDeployedTo": "staging"`, the release is denied unless the change already has a succeeded deployment in staging: "Not yet deployed to "staging" — promote there before releasing". Check `allowed` in the response. The fields are on the [API page](https://aicodeops.dev/docs/api). You can run the same check by hand under **Review & Gate → Release gate**: enter a pull request URL or commit SHA and choose **Evaluate gate**. ## Next steps - [Rollback](https://aicodeops.dev/docs/rollback) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [Gated deploys and rollback tracking](https://aicodeops.dev/product/deploy) ## Frequently asked questions ### Does AI CodeOps deploy to my servers? No. It calls a deploy webhook you set per project, and your own pipeline does the deploy. AI CodeOps holds no credentials for your infrastructure. ### Can a policy stop automatic deploys to production? Yes. A release.deploy rule can deny automatic deploys per environment. A denied deploy is recorded as canceled, with the reason, and nothing is sent. ### Can a deploy wait for a human approval? Not as a separate step. The approval happens earlier, on the change, before its pull request opens. Deploy rules can only allow or deny. --- # Roll back a deployment > What rollback means in AI CodeOps: you roll back in your own deploy pipeline, then mark the deployment rolled back so history and failure rate stay accurate. Source: https://aicodeops.dev/docs/rollback · Last updated: 2026-10-18 AI CodeOps doesn't redeploy older versions, call your pipeline to roll back, or roll back on its own. Rollback happens in your deploy pipeline. AI CodeOps keeps the record straight: you mark the deployment as rolled back, and the history and delivery metrics reflect it. ## Mark a deployment as rolled back 1. Roll back in your own deploy pipeline. 2. In AI CodeOps, open **Release → Deployments**. 3. Find the deployment in the history. You can filter by environment and status. 4. Choose **Mark rolled back** on its row. 5. The dialog names the deployment, for example "Mark production @ 3f9c2a1b as rolled back?". Choose **Mark as rolled back**. The dialog says what this does: "This records the deploy as rolled back in the history. It does not redeploy anything: roll back in your deploy pipeline, then mark it here." ## What changes - The deployment's status becomes **rolled back**, with the note "Rolled back via dashboard". If it had no end time, it gets one. - It counts as a failure in the **change failure rate** on the dashboard: failed plus rolled-back deploys, out of all finished ones. It no longer counts toward deployment frequency. - The **Rolled Back** count on the Deployments page goes up. Nothing is sent to your deploy webhook, and no incident is opened. ## Which deployments you can mark - Only **succeeded** or **failed** deployments show **Mark rolled back**. A queued or in-progress deployment doesn't. - Rolled back is final. It can't be changed back. - You need a role that can manage deployments: owners, admins, developers, members and DevOps admins have it; viewers don't. See [Members and roles](https://aicodeops.dev/docs/members). ## Record what you restored Marking a deployment rolled back doesn't record what's running now. To keep the history complete, record the version you restored: choose **Record deployment**, pick the project and environment, set the status, and enter the version or commit SHA. See [Gated deploys](https://aicodeops.dev/docs/gated-deploys). ## Fix forward with a session To fix the problem that caused the rollback, start a [session](https://aicodeops.dev/docs/sessions) on the project. If an incident is open for it, choose **Fix with AI** on the incident. The fix goes through the same tests, review and approval as any other change. ## Next steps - [Gated deploys](https://aicodeops.dev/docs/gated-deploys) - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [Gated deploys and rollback tracking](https://aicodeops.dev/product/deploy) ## Frequently asked questions ### Does AI CodeOps roll back a deploy automatically? No. There is no automatic rollback. You roll back in your deploy pipeline, then mark the deployment rolled back in AI CodeOps. ### Does Mark rolled back redeploy the previous version? No. It only changes the deployment's status in the history. Nothing is sent to your pipeline. ### Can I undo a rolled-back mark? No. Rolled back is a final status. To record the version you restored, record a new deployment. --- # Cost controls > Cap AI spend in AI CodeOps with a workspace budget and per-workflow caps, see cost per session and per step, and read the Usage page's allowance and charts. Source: https://aicodeops.dev/docs/cost-controls AI CodeOps records the cost of every model call, rolls it up per session, and lets you cap what a workspace can spend. Budgets apply to every session, whether it runs on the platform's models, on credits, or on your own provider key. ## Workspace budget Open **Configure → Billing** and find **Cost budget**. With no budget set, the page says "No budget configured. Workflow dispatch is currently unmetered." Choose **Configure budget**: | Field | What it does | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Period** | Daily, Weekly, Monthly (default) or Rolling 30d. Periods start in UTC; weeks start on Monday. | | **Soft limit (USD)** | A marker on the spend bar. Past it, starting a session in the console shows a warning with the period's spend, and the crossing is recorded under **Recent decisions** on **Secure → Policies**. Sessions keep running, and no email or notification is sent. | | **Hard limit (USD)** | New sessions are refused, and running sessions stop, once spend reaches it. | The soft limit must not be higher than the hard limit. A budget can be disabled without deleting it. The panel shows **This period spend** against the hard limit: amber from 70%, red from 90%. Owners, admins and billing admins can set budgets. Creating the budget, changing its limits and turning enforcement on or off are recorded in the audit log as `budget.updated`. ## Per-workflow caps After the budget exists, choose **Edit limits** to set **Per-workflow caps (USD)**: an optional hard cap for each workflow, on top of the workspace limit. Use it to keep an expensive workflow, such as Feature SDLC, within its own limit while quicker ones run freely. There are no per-agent budgets. ## What happens at the limit - **Starting a session:** "Over budget — … Raise the workspace budget before launching." - **During a session:** the budget is checked before every model call. A session that crosses the limit stops with "Stopped over budget" and the status **Blocked by budget**. - **If the check itself fails** when a session starts, the session is blocked rather than run unmetered. If it fails during a session, the session keeps running. A single model call already in flight can take spend slightly past the limit. ## Cost per session - **Develop → AI Sessions** lists the 20 most recent sessions with their **Cost**. - A session's page shows its total cost, and a table of each agent step with its runtime, status, duration, cost and tokens. - **Develop → Changes** shows the cost of each change: what the session that proposed it spent. Tokens from failed model calls are counted too, because the provider charges for them. ## The Usage page **Measure → Usage** has three parts: - **AI allowance this month**: a bar per tier of the platform's models, and when the allowance resets. See [Models and tiers](https://aicodeops.dev/docs/models). - **Cost**: daily spend by model for the month, filterable by model and API key. Owners, admins, DevOps admins and billing admins can see it. - **Usage History**: each model call with its date, model, input and output tokens, cost and session. ## Credits and spending limits On the **Billing** page, workspaces with billing set up can add credits, turn on **Auto Reload**, and set a **Monthly Limit** for credit spend. A session that runs out of credits stops with "Stopped: the workspace's credits ran out." ## Next steps - [Models and tiers](https://aicodeops.dev/docs/models) - [Pricing](https://aicodeops.dev/pricing) - [AI coding cost calculator](https://aicodeops.dev/tools/ai-coding-cost-calculator) ## Frequently asked questions ### Can I set a budget per agent? No. Budgets are per workspace and per workflow. The cost of each agent step is shown on the session's page, so you can see where the money went. ### Does a soft limit stop sessions? No. Past the soft limit, sessions still start, with a warning that shows the period's spend. Crossing it is also recorded on the Policies page. No email or notification is sent. The hard limit and per-workflow caps stop sessions. --- # Usage and spend > See what AI CodeOps spends: cost per session and per agent step, cost by agent across sessions, the Usage page's allowance, daily cost and call history. Source: https://aicodeops.dev/docs/usage-and-spend · Last updated: 2026-10-18 AI CodeOps prices every model call a session makes and adds it up per agent step and per session. This page shows where to read those numbers. To cap spend, see [Cost controls](https://aicodeops.dev/docs/cost-controls). ## What is counted Every model call in a session is recorded with its model, input and output tokens and cost in US dollars: - each agent step, such as plan, build, review and test; - writing the code change; - the AI review of the diff that records findings; - calls that failed partway, because the provider charges for the tokens they used. Questions to the in-console Help assistant are recorded as usage too. Costs are recorded whether the session runs on the platform's models, on credits or on your own provider key. Each call's cost is its tokens times the model's per-token price. With your own key, your provider bills you, and the cost shown is an estimate of that bill. ## Cost per session and per agent **Develop → AI Sessions** lists your 20 most recent sessions with their project, duration, **Cost** and start time. Open a session to see: - its total **Cost**, next to **Agent steps** and **Findings**; - a table of agent steps with **Agent**, **Runtime**, **Status**, **Duration**, **Cost** and **Tokens**. The step costs don't add up to the total: the total also includes writing the change and reviewing its diff. ## Cost by agent **Operate → Monitoring** shows **Total cost (all time)** and **Tokens (all time)** for the workspace, and an **Agent Cost Breakdown** table: for each agent, the number of **Sessions**, the **Total** cost, the **Avg** cost per session and the tokens it used. Use it to see which agents cost the most across all your sessions. ## The Usage page Open **Measure → Usage**. It has up to three parts. ### AI allowance this month A bar per tier of the platform's models (Economy, Standard and Premium) shows how much of your monthly token allowance is used. It turns amber from 80% and red when a tier is used up. See [Models and tiers](https://aicodeops.dev/docs/models) for how allowances work. ### Cost A chart of daily spend for one month, by model. - Use the arrows to move between months. - Filter by model (**All Models**) or by API key (**All Keys**). - Days are shown in your browser's time zone. The Cost chart shows everyone's usage. It appears for roles that can read all usage: owners, admins, DevOps admins and billing admins. ### Usage History Each model call, newest first, with its **Date**, **Model**, **Input** and **Output** tokens, **Cost** and **Session**. Open the input or output count to see the breakdown: cache reads, cache writes and reasoning tokens where the model reports them. Roles that can read all usage see every call. Other roles see only calls made with their own API keys, so session usage isn't listed for them; they can read session costs on the session pages instead. ## Spend limits Tracking and limits work together. The limits that stop spend are: | Limit | Where | What it stops | | --------------------- | -------------------------------------------- | ------------------------------------------ | | Workspace cost budget | **Configure → Billing → Cost budget** | New and running sessions at the hard limit | | Per-workflow caps | **Cost budget → Edit limits** | Sessions of that workflow | | Monthly allowance | Your plan, per tier | Platform-model calls on that tier | | Monthly Limit | **Configure → Billing**, with billing set up | Spending of credits | All of them are explained in [Cost controls](https://aicodeops.dev/docs/cost-controls). There are no per-agent budgets; use the step costs above to see where the money went. ## Who can see what | What | Who | | ----------------------------------------- | ------------------------------------------------------ | | Session and step costs, Monitoring totals | Anyone who can open those pages | | Usage page: allowance and own usage | Roles that can read their own usage, including viewers | | Usage page: Cost chart and all calls | Owners, admins, DevOps admins and billing admins | | Cost budget | Owners, admins and billing admins can change it | See [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions) for the full list. ## Next steps - [Cost controls](https://aicodeops.dev/docs/cost-controls) - [Models and tiers](https://aicodeops.dev/docs/models) - [Pricing](https://aicodeops.dev/pricing) ## Frequently asked questions ### Why don't the agent steps add up to the session's cost? The session total also includes work outside the agent steps, such as writing the code change and the review of its diff. ### Can I export usage as CSV? Not yet. The Usage page and the session pages are the way to read usage during the open beta. ### Does the Help assistant use my allowance? Yes, when it runs on the platform's models. Its answers are recorded as usage like a session's model calls. --- # Members and roles > Invite people to an AI CodeOps workspace, choose built-in roles from owner to viewer, create custom roles on Enterprise, and require two-factor sign-in. Source: https://aicodeops.dev/docs/members A workspace holds your projects, sessions and settings. Everyone in it has a role, and the role decides what they can see and do. Every change to members and roles is recorded in **Measure → Audit Log**. ## Built-in roles | Role | What it can do | | --------- | ------------------------------------------------------------------------------------------------------- | | Owner | Full access, including making other owners. | | Admin | Full access, except making owners or changing an owner's role. | | Developer | Runs AI sessions; manages projects, agents, schedules, deployments and incidents; manages own API keys. | | Member | Runs AI sessions; manages deployments, incidents and decision records; manages own API keys. | | Viewer | Read-only. Can't run sessions or create API keys. | There are also separation-of-duties roles for larger teams: | Role | What it can do | | -------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Security Admin | Policies, audit and approvals. No billing or secrets. | | DevOps Admin | Projects, runbooks, schedules, deployments and incidents. No billing, members or secrets, and can't change models or providers. | | Billing Admin | Billing, budgets and usage. No access to code, secrets or members. | | Secret Manager | Workspace secrets only. | Every plan offers all of these roles. SSO isn't part of any workspace role: it belongs to your organization's owners and admins. See [Single sign-on](https://aicodeops.dev/docs/sso). ### Rules for assigning roles - You can't give anyone a role at or above your own level, or change the role of someone at or above it. - Only an owner can assign administrative roles (any role that can change settings, assign roles or create roles). - A workspace must keep an owner. To hand over ownership, make another member an owner, then step down. ## Invite people 1. Open **Configure → Members** and choose **Invite Member**. 2. Enter their email address and choose a role. 3. They get an email. When they sign in or sign up with that same address, they join the workspace. If the email can't be sent, you'll see "Invited, but no email could be sent." Ask them to sign up with the invited address; they join when they do. Organization admins can also invite from **Configure → Settings → Organization & Teams**. That sends an invitation link you can copy and share. The link expires after 7 days, must be accepted with the email address it was sent to, and can be revoked under **Pending Invitations** before it is used. You can send up to 30 invitations a minute. ## Remove a member On **Configure → Members**, choose **Delete** on the member's row and confirm **Remove member**. Their workspace access and their API keys are revoked at once. You can't remove yourself, someone at or above your level, or the last owner. ## Custom roles On Enterprise, owners and admins can create custom roles under **Configure → Settings → Roles & Permissions**. Give the role a name and a slug, then pick permissions from groups such as Workspace, Members, API Keys, Models & Providers, Projects & Operations, Governance & Secrets, Usage & Billing, Sessions and Security. - You can't grant permissions you don't hold yourself. - Only an owner can edit a role that has administrative permissions, or add them to an existing role. - A role that is still assigned can't be deleted. Reassign its members first. ## Two-factor authentication Each person sets up two-factor sign-in from **Configure → Settings → Multi-Factor Authentication**: an authenticator app (TOTP) or a passkey (hardware key, fingerprint or Face ID). Ten recovery codes are issued when you add your first factor. Two-factor sign-in is required for owners and admins, and for any role with sensitive permissions such as managing secrets, providers, SSO, policies, members or billing. Depending on your plan, developers and members may be required to enroll too. Anyone who must enroll is asked to before they continue. ## Next steps - [Single sign-on](https://aicodeops.dev/docs/sso) - [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies) - [API keys](https://aicodeops.dev/docs/api) ## Frequently asked questions ### Can an admin make someone else an admin? No. Only an owner can assign administrative roles. Everyone else can only assign roles below their own level. ### What happens to a removed member's API keys? They are revoked when the member is removed, along with the member's access to the workspace. --- # Roles and permissions > Every built-in AI CodeOps role and what it can do: who starts sessions, who approves changes, who edits policies, plus custom roles and how roles are assigned. Source: https://aicodeops.dev/docs/roles-and-permissions · Last updated: 2026-10-18 Everyone in a workspace has one role. The role is a set of permissions, and each permission unlocks one kind of action. This page lists what each built-in role holds. To invite people and change their roles, see [Members and roles](https://aicodeops.dev/docs/members). Roles govern people. What AI sessions may do on their own is set by the [workspace policy](https://aicodeops.dev/docs/policy-engine). ## Built-in roles | Role | In short | | -------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Owner | Full access, including making other owners. | | Admin | Full access except deleting the workspace and transferring ownership. | | Developer | Runs AI sessions and manages projects, agents, schedules, deployments and incidents. Manages own API keys. | | Member | Runs AI sessions and manages deployments, incidents and decision records. Manages own API keys. | | Viewer | Read-only. Can't run sessions or create API keys. | | Security Admin | Policies, the audit log, approvals and finding triage. No billing, secrets or sessions. | | DevOps Admin | Projects, runbooks, schedules, deployments, incidents, MCP servers, agents and notifications. No billing, members or secrets. | | Billing Admin | Billing, budgets and usage. No access to code, secrets or members. | | Secret Manager | Workspace secrets only. | The last four are separation-of-duties roles: each covers one area, so a single compromised admin account can do less. ## Who can do what | Action | Owner | Admin | Developer | Member | Viewer | Security Admin | DevOps Admin | Billing Admin | Secret Manager | | --------------------------------------------- | :---: | :---: | :-------: | :----: | :----: | :------------: | :----------: | :-----------: | :------------: | | Start, cancel and re-run AI sessions | Yes | Yes | Yes | Yes | No | No | Yes | No | No | | Approve or reject changes | Yes | Yes | No | No | No | Yes | No | No | No | | Triage findings | Yes | Yes | Yes | Yes | No | Yes | Yes | No | No | | Manage projects | Yes | Yes | Yes | No | No | No | Yes | No | No | | Manage deployments and incidents | Yes | Yes | Yes | Yes | No | No | Yes | No | No | | Manage custom agents and schedules | Yes | Yes | Yes | No | No | No | Yes | No | No | | Manage MCP servers and notification endpoints | Yes | Yes | No | No | No | No | Yes | No | No | | Add model provider keys and change settings | Yes | Yes | No | No | No | No | No | No | No | | Edit the workspace policy | Yes | Yes | No | No | No | Yes | No | No | No | | Read the audit log | Yes | Yes | No | No | No | Yes | No | No | No | | Create own API keys | Yes | Yes | Yes | Yes | No | No | No | No | No | | See everyone's usage and cost | Yes | Yes | No | No | No | No | Yes | Yes | No | | Manage billing and the cost budget | Yes | Yes | No | No | No | No | No | Yes | No | | Manage workspace secrets | Yes | Yes | No | No | No | No | No | No | Yes | | Invite and remove members | Yes | Yes | No | No | No | No | No | No | No | | Create custom roles | Yes | Yes | No | No | No | No | No | No | No | Every role can see the workspace and its member list, and manage its own two-factor methods and sign-in sessions. Single sign-on is managed by the organization's owners and admins, not by a workspace role. See [Single sign-on](https://aicodeops.dev/docs/sso). ### Approving changes Approvals need the approval-decide permission. A request can also name specific approvers. The person who launched a session can't approve its change while someone else in the workspace can approve; a solo team can approve its own work. Details are in [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies). ### Running sessions Starting, cancelling, re-running and fixing a finding with AI all need the run-manage permission. A role without it can still open sessions and read their results. ## Custom roles On the Enterprise plan, owners and admins can create roles with exactly the permissions they need. 1. Open **Configure → Settings** and find **Roles & Permissions**. 2. Under **Custom Roles**, choose **Create Role**. 3. Enter a **Role Name** and a **Slug**. 4. Tick the permissions. They are grouped, for example Workspace, Members, API Keys, Models & Providers, Projects & Operations, Governance & Secrets, and Usage & Billing. 5. Choose **Create Role**. Assign it under **Role Assignment** on the same page, or when you invite someone. Changes take effect immediately. - You can't grant a permission you don't hold yourself. - Only an owner can change a role that has administrative permissions: changing settings, deleting the workspace, assigning roles or creating roles. Only an owner can assign such a role. - A role that is still assigned can't be deleted. - **Remove members** lets a custom role remove members, but never an owner or an admin: only an owner removes those. - If the organization leaves the Enterprise plan, custom roles keep only the permissions a Member has. ## Rules for assigning roles - An owner can assign any role. - An admin can assign any role that isn't administrative. - You can't change or remove someone at or above your own level. - A workspace must always keep an owner. Every role change is recorded as `role.changed` in the [audit log](https://aicodeops.dev/docs/audit-logs). ## Two-factor sign-in Owners, admins, the four separation-of-duties roles and any custom role with sensitive permissions, such as managing secrets, policies, members or billing, must set up two-factor sign-in. Developers must on Pro and Enterprise, members on Enterprise, and viewers never. See [Members and roles](https://aicodeops.dev/docs/members). ## Next steps - [Members and roles](https://aicodeops.dev/docs/members) - [Audit logs](https://aicodeops.dev/docs/audit-logs) - [Single sign-on](https://aicodeops.dev/docs/sso) ## Frequently asked questions ### Can a developer approve an AI change? Not with the built-in Developer role. Approving needs the approval-decide permission, which owners, admins and security admins have. A custom role can include it. ### Which roles can start AI sessions? Owners, admins, developers, members and DevOps admins. Viewers, security admins, billing admins and secret managers can't. ### Do roles apply to API keys? Yes. A workspace API key acts as the member who created it, with that member's current role. --- # Audit logs > What the AI CodeOps audit log records, how to read and filter it under Measure → Audit Log, who can see it, and how long entries are kept on each plan. Source: https://aicodeops.dev/docs/audit-logs · Last updated: 2026-10-18 The audit log records who changed what in a workspace: members and roles, keys, providers, policies, agents, schedules, budgets, secrets, approvals and the code AI sessions generate. Each entry has a time, the account that acted, the target, the IP address and a short description. ## What is recorded | Area | Actions | | -------------------- | ------------------------------------------------------------------------------------------------------------------- | | Members and roles | `member.invited`, `member.removed`, `role.changed` | | API keys | `apikey.created`, `apikey.revoked`, `apikey.scope.updated`, `apikey.scope.removed` | | Model providers | `provider.credential.added`, `provider.credential.removed` | | Policies and budgets | `policy.updated`, `budget.updated` | | Secrets | `secret.created`, `secret.updated`, `secret.toggled`, `secret.deleted` | | Approvals | `approval.decided`, `approval.canceled` | | Agents and tools | `agent.created`, `agent.updated`, `agent.deleted`, `mcp_server.created`, `mcp_server.updated`, `mcp_server.deleted` | | Marketplace | `marketplace.installed`, `marketplace.uninstalled` | | Schedules | `schedule.created`, `schedule.updated`, `schedule.deleted` | | Generated code | `session.code.edited`, `session.code.created`, `session.code.deleted` | | Sessions | `session.canceled` (with the reason given) | | Deployments | `deployment.recorded`, `deployment.status_changed`, `deploy_target.updated` | | Evidence and sharing | `change.evidence_exported`, `workspace.share_enabled`, `workspace.share_disabled` | | Workspace | `workspace.updated` | `session.code.*` entries record edits a person makes to the code a session generated, before it becomes a pull request. Sign-ins, two-factor changes and SSO configuration are recorded too, but against the account or organization rather than a workspace. They don't appear on a workspace's Audit Log page, and they are kept for 7 days on every plan. ## Read the audit log 1. Open **Measure → Audit Log**. 2. To narrow it down, pick an action under **Action**. The list offers only actions this workspace has recorded. **All actions** shows everything. 3. Use **← Prev** and **Next →** to page through, 50 entries at a time. Each row shows **When**, **Action**, **Account**, **Target**, **IP** and **Detail**. **Account** is the account ID of the person who acted. For a broader view of what happened in the workspace, including sessions and deployments, follow the **Activity feed →** link at the top of the page. ## Who can read it Reading the audit log needs the audit-read permission. Owners, admins and security admins have it; developers, members and viewers don't. A custom role can include it. Without it, the page says so and asks you to contact a workspace admin. See [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions). ## Retention How long entries are kept depends on your organization's plan: | Plan | Kept for | | ---------- | ---------------------------------- | | Free | 7 days | | Pro | 90 days | | Enterprise | As long as the organization exists | Older entries are deleted once a day. The same windows apply to the policy decisions shown under **Secure → Policies**. - Entries of a deleted workspace are deleted after 7 days. - Sign-in, two-factor and other account-level entries are kept for 7 days on every plan. More in [Data retention](https://aicodeops.dev/docs/data-retention). ## Exporting There is no audit export in the open beta. To keep a record outside AI CodeOps: - [Evidence packs](https://aicodeops.dev/docs/evidence-packs) give you a signed record of a single change, including its review and approval. - Your account data export, under **Configure → Settings → Your data**, includes your own audit events. ## Next steps - [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions) - [Data retention](https://aicodeops.dev/docs/data-retention) - [Audit and RBAC](https://aicodeops.dev/product/audit-rbac) ## Frequently asked questions ### Can I export the audit log? Not yet. There is no export button in the open beta. Your own audit events are included in your account data export. ### Who can read the audit log? Owners, admins and security admins, or any custom role with the audit-read permission. ### How long are audit entries kept? Workspace entries are kept 7 days on Free, 90 days on Pro, and for as long as the organization exists on Enterprise. Account and SSO entries are kept 7 days on every plan. --- # Set up single sign-on (SSO) > Set up SAML 2.0 or OpenID Connect sign-in for AI CodeOps on the Enterprise plan: verify your domain, create a connection, configure your IdP and activate it. Source: https://aicodeops.dev/docs/sso · Last updated: 2026-10-18 Single sign-on lets your people sign in to AI CodeOps through your own identity provider (IdP), with SAML 2.0 or OpenID Connect (OIDC). Any IdP that supports either protocol works; you enter its details yourself, so there are no provider presets. ## Before you start - **Plan.** SSO is part of the Enterprise plan, and so is domain verification. Without it, the card shows "SSO (SAML 2.0 / OIDC) is available on the Enterprise plan." See [Enterprise](https://aicodeops.dev/enterprise). - **Who can set it up.** SSO belongs to the organization, not a single workspace. Organization owners and admins see the card. Only an owner can create, edit and activate a connection. Owners and admins can verify domains, set the SSO default workspace, and deactivate and delete connections. - **DNS access.** You need to add a TXT record for your email domain. The settings are in **Configure → Settings**, in the **Single sign-on** card. ## 1. Verify your domain 1. Under **Verified Domains**, enter your email domain, for example `example.com`, and choose **Verify a domain**. 2. Add the TXT record shown to your DNS: - Name: `_codeopsstudio-verify.example.com` - Value: the token on screen 3. Choose **Check now**. DNS changes can take a while to appear, so check again later if it isn't verified yet. You can't create a connection for a domain until it is verified. ## 2. Create a connection 1. Choose **Add SSO connection**. 2. In **New SSO Connection**, fill in: | Field | SAML 2.0 | OpenID Connect | | ---------------- | ------------------------------------------------------------- | ------------------------------------------------ | | **Protocol** | SAML 2.0 | OpenID Connect | | **Display Name** | A name you recognise, such as "Okta" | A name, such as "Azure AD" | | **Email Domain** | A verified domain | A verified domain | | **Default Role** | Member, Developer or Viewer | Member, Developer or Viewer | | IdP details | **IdP Entity ID**, **IdP SSO URL**, **IdP Certificate (PEM)** | **Issuer URL**, **Client ID**, **Client Secret** | 3. Choose **Create Connection**. The OIDC client secret is encrypted at rest. There is no field for an IdP metadata URL; copy the values from your IdP. ## 3. Configure your identity provider The connection card shows the values your IdP needs: | Protocol | Label | Path | Use | | -------- | ---------------- | ------------------------------------ | -------------------------------------------- | | SAML | **Metadata URL** | `/sso/saml//metadata` | Service provider metadata, and its entity ID | | SAML | **ACS URL** | `/sso/saml//acs` | Assertion Consumer Service (HTTP-POST) | | OIDC | **Redirect URI** | `/sso/oidc//callback` | Redirect URI for your OIDC app | Paths are on the console's address, for example `https://console.aicodeops.dev`. **SAML.** Send the user's email address as the NameID (email address format) or as an `email` attribute. Assertions must be signed with the certificate you entered. AI CodeOps checks the signature, the audience, the expiry and that the response answers a sign-in it started. Sign-in must start at AI CodeOps; a tile on your IdP's dashboard won't work. **OIDC.** AI CodeOps requests the `openid email profile` scopes and uses PKCE. ## 4. Activate and share the link A new connection is in testing until you activate it. While it is, it signs in only people who are already in your organization, and creates no accounts. To try it with your own account, open `/sso/saml//login` or `/sso/oidc//login` on the console's address. 1. On the connection card, choose **Activate**. 2. Share the sign-in link with your people: ```text https://console.aicodeops.dev/sso/login?domain=example.com ``` The link opens **Continue with single sign-on** if the domain is missing, so people can also type their work email there. It finds the active connection for the domain and sends them to your IdP. ## New users and roles The first SSO sign-in creates the person's account if they don't have one and adds them to your organization. To put new people straight into a workspace, open that workspace's settings and choose **Set this workspace as SSO default** on the connection card. They join it with the connection's **Default Role**. Without a default workspace they land in their own personal workspace until someone [invites them](https://aicodeops.dev/docs/members). You can change their role later; see [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions). ## Sessions stay inside your organization A sign-in through your SSO only reaches your organization's workspaces and the person's own personal workspace. Workspaces of other organizations are blocked for that session, even if the person is a member there. ## Deactivate or delete - **Deactivate** stops new SSO sign-ins and keeps the setup. - **Delete** removes the connection after you confirm **Delete connection**. Its users then sign in with a password or a social account. SSO changes are recorded as `sso.connection.*` and `sso.domain.*` audit events against the organization. They don't appear on a workspace's [audit log](https://aicodeops.dev/docs/audit-logs) page, and they are kept for 7 days. ## Next steps - [Enterprise overview](https://aicodeops.dev/docs/enterprise) - [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions) - [Enterprise plan](https://aicodeops.dev/enterprise) ## Frequently asked questions ### Which plan includes SSO? Enterprise. On other plans the Single sign-on card says SSO is available on the Enterprise plan. ### Where is the SAML metadata URL? On the connection card after you create the connection, labelled Metadata URL. It has the form /sso/saml//metadata and is also the service provider entity ID. ### Can people still sign in with a password once SSO is on? Yes. SSO adds a way to sign in; it doesn't turn off password or social sign-in for your domain. --- # Data retention and deletion > How long AI CodeOps keeps sessions, audit records, delivery logs and backups, how to export your account data, how deletion works, and how your code is used. Source: https://aicodeops.dev/docs/data-retention · Last updated: 2026-10-18 This page covers what AI CodeOps keeps, for how long, and how to get a copy of your data or delete it. The legal terms are in the [Privacy Policy](https://aicodeops.dev/legal/privacy-policy). ## How long data is kept | Data | Kept for | | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | Workspace content: tasks, sessions and their output, changes, findings, approvals, plans | As long as the workspace exists | | Audit log and policy decisions | 7 days on Free, 90 days on Pro, as long as the organization exists on Enterprise | | Account-level audit events, such as sign-ins and two-factor changes | 7 days | | Audit records of a deleted workspace | 7 days | | Webhook delivery history for notification endpoints | 30 days | | Sign-in sessions | 7 days after they expire; 45 days after you sign out | | Sign-in challenges | Until the day after they expire | | Request counters per IP address | 2 days | | Billing and usage records | As long as tax and accounting law requires, also after deletion | | Database backups | 7 days, or up to 30 days with continuous off-site backups | Expired records are removed by a daily clean-up. Deleted data disappears from backups once those backups age out. More on the audit log in [Audit logs](https://aicodeops.dev/docs/audit-logs). ## Export your data You can download everything AI CodeOps holds about your account at any time. 1. Open **Configure → Settings**. 2. Find **Your data** and the row **Export your data**. 3. Choose **Download**. You get a JSON file named `aicodeops-export-.json`. It includes your profile, sign-in identities and sessions, workspace and organization memberships, connected Git accounts, two-factor methods, API key names, the tasks you ran and their results, approvals, invitations, support tickets and your audit events. Secret values and keys are not included. ## Delete your account 1. Open **Configure → Settings** and scroll to **Danger Zone**. 2. Choose **Delete account**. 3. Type `DELETE` and choose **Permanently delete**. Deletion takes effect at once and can't be undone: - Your account is erased, along with every workspace where you are the only member. - In workspaces others still use, the workspace and its content stay with its organization. - Audit records that are kept are anonymized: your account ID, IP address, browser and email address are removed. They are then deleted on the normal schedule. - Billing and usage records are kept as the law requires. ## Delete a workspace or organization There is no button for deleting a single workspace or a whole organization in the console. When an organization is deleted, every workspace in it is deleted with its content. To delete one, the organization owner can [contact support](https://aicodeops.dev/docs/contact-support). ## How your code and prompts are used When a session runs, its task, the code and files it works on, and its output are sent to an AI model provider: either the provider your workspace connects with its own key, or the provider the platform uses, named on the [Trust page](https://aicodeops.dev/trust). - AI CodeOps doesn't use your content to train or fine-tune AI models, and doesn't sell it. - Model providers process your content under their own API terms, including how long they keep it. Check those terms for any provider you connect yourself. ## Where data is stored AI CodeOps's servers and database are in the United States. The service providers that process data, and their regions, are listed on the [Trust page](https://aicodeops.dev/trust). ## Next steps - [Privacy Policy](https://aicodeops.dev/legal/privacy-policy) - [Security](https://aicodeops.dev/security) - [Audit logs](https://aicodeops.dev/docs/audit-logs) ## Frequently asked questions ### Does AI CodeOps train AI models on my code? No. AI CodeOps doesn't use your content to train or fine-tune AI models. Model providers process it under their own API terms. ### Is there a grace period after I delete my account? No. Deleting your account takes effect immediately and can't be undone. Export your data first. ### Where is my data stored? AI CodeOps's servers and database are in the United States. Service providers and their regions are listed on the Trust page. --- # Enterprise overview > What the AI CodeOps Enterprise plan adds: SSO with SAML or OIDC, custom roles, audit history kept for the life of your organization, and self-hosting. Source: https://aicodeops.dev/docs/enterprise Enterprise is the AI CodeOps plan for organizations that need their own sign-in, finer control over roles and a longer audit history. It is priced per seat. To get it, [contact sales](https://aicodeops.dev/enterprise). ## What Enterprise adds - **Single sign-on** with SAML 2.0 or OpenID Connect. - **Custom roles**, built from individual permissions. - **Audit history** kept for as long as your organization exists. - **Self-hosted deployment**, an Enterprise option on request. The AI allowance for each plan is on the [pricing page](https://aicodeops.dev/pricing). ## Single sign-on Your people can sign in through your own identity provider. A sign-in through your SSO only reaches your organization's workspaces and the person's own personal workspace. SSO adds a way to sign in; it doesn't turn off password or social sign-in. SSO belongs to the organization, so it is set up by the organization's owners and admins. For the steps, see [Single sign-on](https://aicodeops.dev/docs/sso). ## Custom roles On Enterprise, owners and admins can create roles under **Configure → Settings → Roles & Permissions**, on top of the built-in roles every plan has. See [Members and roles](https://aicodeops.dev/docs/members) and [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions). ## Audit history Workspace audit log entries are kept for as long as the organization exists. SSO configuration changes are recorded against the organization instead, and are kept for 7 days. See [Audit logs](https://aicodeops.dev/docs/audit-logs). ## Self-hosted deployment Running AI CodeOps in your own environment is available to Enterprise customers only, on request. See [Self-hosted deployment](https://aicodeops.dev/docs/self-hosted). ## Next steps - [Single sign-on](https://aicodeops.dev/docs/sso) - [Members and roles](https://aicodeops.dev/docs/members) - [Enterprise plan](https://aicodeops.dev/enterprise) ## Frequently asked questions ### How do we get the Enterprise plan? Contact sales. Enterprise is set up with you and priced per seat; it can't be bought self-serve. ### Where are the SSO setup steps? In the Single sign-on guide. It covers verifying your domain, creating a connection, configuring your identity provider and activating it. --- # Self-hosted deployment > An overview of running AI CodeOps on your own Kubernetes cluster, an Enterprise option on request: what it involves, what it needs, and how to get started. Source: https://aicodeops.dev/docs/self-hosted · Last updated: 2026-10-18 Most teams use AI CodeOps as a hosted service in the browser. Some organizations need their code and run history to stay on their own infrastructure. For them, self-hosted deployment is available as an Enterprise option, on request. It is not a separate product and has no public install steps: it is planned with you, and the installation guide is shared privately with Enterprise customers. This page gives an overview so you can judge whether it fits. To start, [contact sales on the Enterprise page](https://aicodeops.dev/enterprise). ## What you get A self-hosted Enterprise install runs the same browser-based product your team would use on the hosted service, in your own Kubernetes cluster: - your code, sessions, changes and audit history stay in your database; - you choose the AI model provider your sessions use; - secrets can come from your own secrets store; - people sign in through your identity provider with [SSO](https://aicodeops.dev/docs/sso). ## What it involves AI CodeOps is deployed with a Helm chart. At a high level, an Enterprise install involves: | Part | What it is | | -------------------- | ---------------------------------------------------------------------------------------------- | | Kubernetes | A cluster running Kubernetes 1.27 or later. | | Application services | The web console, the sign-in service, an operations service, and workers that run AI sessions. | | Scheduled jobs | Jobs for schedules, approvals, monitoring, notification retries and data retention. | | PostgreSQL | The main database. Schema migrations run as a job before each upgrade. | | Redis | Used alongside the database by the application services. | | Ingress and TLS | An ingress controller and certificates for the console's address. | | Sandboxes | Optional isolated containers for test runs and terminals, with restricted network access. | | Secrets | Kubernetes secrets, or your secrets store. | Your team also connects the services AI CodeOps talks to: your Git host, your model provider and your email delivery. The exact sizing, storage, backup and network design depend on your environment, and are agreed during planning. ## How to start 1. Open the [Enterprise page](https://aicodeops.dev/enterprise) and fill in the contact form. 2. Tell us about your environment: your Kubernetes platform, Git host, model provider and identity provider. 3. We plan the deployment with you and share the installation guide. ## Next steps - [Enterprise](https://aicodeops.dev/enterprise) - [Enterprise overview](https://aicodeops.dev/docs/enterprise) - [Data retention and deletion](https://aicodeops.dev/docs/data-retention) ## Frequently asked questions ### Can I self-host AI CodeOps on the free plan? No. Self-hosted deployment is available to Enterprise customers only, on request. The open beta runs on the hosted service. ### Is there a public installation guide? No. For Enterprise customers, the installation guide is shared privately and the deployment is planned with you. ### Does a self-hosted install need a desktop app or CLI? No. A self-hosted Enterprise install is the same browser-based product, running on your infrastructure. --- # API > What you can call programmatically today: the release gate check for CI with a workspace API key, and the public evidence pack keys. The API is limited in beta. Source: https://aicodeops.dev/docs/api AI CodeOps is used in the browser. During the open beta, the programmatic API is deliberately small: one endpoint for CI, plus the public keys that let anyone check an evidence pack. Everything else in the console needs a signed-in browser session and is not a supported API. There is no published OpenAPI specification yet. ## Workspace API keys Create a key under **Configure → API Keys**. Give it a name; the secret (it starts with `sk-`) is shown once, so copy it then. AI CodeOps stores only a hash. - A key acts as the member who created it, with that member's current role. If the member is removed or their role loses a permission, the key loses it too. - Owners, admins, developers and members can create keys. Viewers can't. - Admins see every key in the workspace; others see their own. - **Delete** revokes a key at once. Integrations using it stop working immediately. Where your plan includes key scoping, an admin can choose **Scope** to limit a key to an IP allowlist (CIDR ranges), a rate limit per minute, an expiry date, and what it may be used for: model gateway calls, the release gate check, or both (the default). Send the key as a Bearer token: ```http Authorization: Bearer sk-... ``` ## Release gate check `POST /api/release/check` answers one question for your CI: may this pull request or commit ship? It applies the same checks as the [quality gates](https://aicodeops.dev/docs/quality-gates) across every session that touched the change. The key needs the `workspace:read` permission. ```bash curl -sf -X POST "https://console.aicodeops.dev/api/release/check" \ -H "Authorization: Bearer $WORKSPACE_API_KEY" \ -H "Content-Type: application/json" \ -d '{"pullRequestURL":"https://github.com/acme/api/pull/42"}' ``` Use the same host you open the console on. ### Request fields | Field | Type | Default | | -------------------- | ---------------------------------------------- | ---------------------------- | | `pullRequestURL` | URL | one of these two is required | | `commitSHA` | string, 7+ characters | | | `blockingSeverity` | `critical`, `high`, `medium`, `low`, `info` | `high` | | `blockOnTestFailure` | boolean | `true` | | `minCoveragePct` | number 0–100 | not gated | | `requiredWorkflows` | string array | none | | `disallowedLicenses` | string array, checked against the project SBOM | none | | `requireDeployedTo` | environment name, e.g. `staging` | none | | `blockOnInFlight` | boolean: deny while a run is still going | `false` | | `lookbackMs` | how far back to look, in milliseconds | 14 days | `GET /api/release/check` accepts the same names as query parameters (lists comma-separated). ### Response The endpoint returns `200` for both outcomes. Read `allowed`: - `allowed`: `true` or `false` - `summary` and `reasons`: plain-English explanations - `blockingFindings`, `testFailures`, `coverageShortfall`, `licenseViolations`, `licenseEvidenceMissing`: the details behind a deny (`licenseEvidenceMissing` lists projects with no SBOM to check when you pass `disallowedLicenses`) - `runsConsidered`: the sessions the verdict was based on A change with no matching sessions is denied ("No workflow runs found for …"). If the evaluation fails, you get `allowed: false` with the summary "Evaluation failed", so a broken check never passes a change. ### Errors | Status | Meaning | | ------ | ------------------------------------------------------------------------------------------------- | | 400 | Invalid JSON or invalid fields | | 401 | Missing or invalid API key | | 403 | The key's scope or its creator's role doesn't allow this, or the key belongs to another workspace | | 429 | More than 60 checks a minute for the workspace; see `Retry-After` | The same check is in the console under **Review & Gate → Release gate**. ## Evidence pack keys `GET /api/evidence?action=keys` is public and needs no key. It returns the Ed25519 public keys that sign [evidence packs](https://aicodeops.dev/docs/evidence-packs), so you can verify a pack offline. Downloading a pack needs a signed-in member with audit access; it is not available with an API key. ## API reference One page per endpoint, generated from the [OpenAPI spec](https://aicodeops.dev/docs/api/openapi.json): - [Check whether a pull request or commit may ship](https://aicodeops.dev/docs/api/release-check) - [The keys that sign evidence packs](https://aicodeops.dev/docs/api/evidence-keys) - [Verify an evidence pack](https://aicodeops.dev/docs/api/evidence-verify) - [Liveness and readiness](https://aicodeops.dev/docs/api/health) - [Component status](https://aicodeops.dev/docs/api/status) ## Next steps - [Quality gates](https://aicodeops.dev/docs/quality-gates) - [Members and roles](https://aicodeops.dev/docs/members) - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) ## Frequently asked questions ### Is there a full REST API for sessions and projects? Not yet. During the open beta the console is the way to run sessions and manage projects. The endpoints on this page are the ones that accept programmatic access. ### Do API keys expire? Not by default. A key works until it is deleted, its creator leaves the workspace, or an expiry date set in its scope passes. --- # Webhooks > Send AI CodeOps events to Slack, Discord, Teams or your own HTTPS endpoint, verify signed payloads, and call your deploy pipeline when a change merges. Source: https://aicodeops.dev/docs/webhooks · Last updated: 2026-10-18 AI CodeOps sends webhooks out; it doesn't take them in. You can: - send workspace events to chat or to your own endpoint, with **notification endpoints**; - call your deploy pipeline when an AI CodeOps pull request is merged, with **deploy webhooks**. ## No incoming Git webhooks AI CodeOps doesn't register webhooks on your repositories and has no endpoint for Git host events. It works with GitHub, GitLab, Bitbucket, Gitea and Forgejo through the account you connect, and checks the state of a pull request by asking your Git host. A self-managed Git server needs no inbound webhook either, but AI CodeOps must be able to reach it: use its public https address (a server on a private network works only if the operator allowlists it). See [Connect GitHub](https://aicodeops.dev/docs/git/github) and the other Git guides. ## Notification endpoints ### Add an endpoint 1. Open **Configure → Settings** and find **Notification endpoints**. 2. Choose **Add endpoint**. 3. Fill in: - **Name**: for example "On-call Slack channel". - **Kind**: Slack, Discord, MS Teams or Generic webhook. - **Target URL**: the incoming-webhook URL from your chat tool, or your own endpoint. - **Min severity**: info (all), low+, medium+, high+ or critical only. - **Events to send**: tick the events you want. None ticked means all events. - **Signing secret** (Generic webhook only): at least 8 characters. 4. Choose **Create endpoint**. Owners, admins and DevOps admins can manage endpoints. See [Roles and permissions](https://aicodeops.dev/docs/roles-and-permissions). The target URL must be a public HTTPS address. Deliveries to `localhost`, private networks or cloud metadata addresses are refused, and redirects aren't followed. ### Events | Event | Kind | When | | ------------------ | -------------------------- | ------------------------------------------------- | | Deploy failed | `deployment.failed` | A deployment failed | | Deploy succeeded | `deployment.completed` | A deployment succeeded | | Deploy recorded | `deployment.recorded` | Any deployment record, in any status | | Incidents & policy | `policy_decision.recorded` | An incident opens or changes, or a policy decides | | Approval requested | `approval.requested` | A request is waiting for a decision | | Approval decided | `approval.decided` | A request was approved or rejected | | Run completed | `workflow_run.completed` | A session finished | | New finding | `agent_finding.created` | A review raised a finding | | Schedule failed | `schedule.failed` | A scheduled workflow couldn't run | With no events ticked, the endpoint also receives session and agent-step progress updates. **Min severity** filters only events that carry a severity, such as findings, incidents and failed schedules. Events without one are always sent. ### Payloads Slack and Microsoft Teams get `{"text": ""}`. Discord gets `{"content": ""}`. The summary is one line, for example: ```text Deploy prj_01JA2B3C4D5E6F7G8H9J0K1M2R → production @ 3f9c2a1b: failed — The deploy webhook answered HTTP 502. ``` A **Generic webhook** gets the summary and the event as JSON, with `Content-Type: application/json`: ```json { "summary": "Deploy prj_01JA2B3C4D5E6F7G8H9J0K1M2R → production @ 3f9c2a1b: failed — The deploy webhook answered HTTP 502.", "event": { "kind": "deployment.failed", "workspaceID": "wrk_01JA2B3C4D5E6F7G8H9J0K1M2N", "entityID": "dep_01JA2B3C4D5E6F7G8H9J0K1M2P", "workflowRunID": "wfr_01JA2B3C4D5E6F7G8H9J0K1M2Q", "status": "failed", "emittedAt": "2026-10-18T09:00:00.000Z", "metadata": { "projectID": "prj_01JA2B3C4D5E6F7G8H9J0K1M2R", "environment": "production", "sequence": 3, "commitSHA": "3f9c2a1b7d4e5f60718293a4b5c6d7e8f9012345", "strategy": "rolling", "errorSummary": "The deploy webhook answered HTTP 502." } } } ``` Every event has `kind`, `workspaceID`, `entityID` and `emittedAt`. `workflowRunID`, `status` and `metadata` appear when they apply. The event is light: fetch details from the console if you need them. ### Verify the signature A Generic webhook with a signing secret sends two headers: ```http X-CodeOps-Signature: sha256= X-CodeOps-Event: deployment.failed ``` To verify, compute the HMAC-SHA256 of the raw request body with your secret and compare it with the header in constant time. For example, in Node.js: ```js import { createHmac, timingSafeEqual } from "node:crypto" function verify(rawBody, header, secret) { const expected = "sha256=" + createHmac("sha256", secret).update(rawBody).digest("hex") return header.length === expected.length && timingSafeEqual(Buffer.from(header), Buffer.from(expected)) } ``` Use the body bytes exactly as received, before parsing the JSON. The signature has no timestamp, so to drop duplicates, use `kind`, `entityID` and `emittedAt` together; `emittedAt` stays the same when a delivery is retried. ### Test, retries and the delivery log Each endpoint has **Test**, **Deliveries**, **Disable** and **Delete**. - **Test** sends a sample event at once, whatever the endpoint's filters. - **Deliveries** shows each attempt with its status, event kind, HTTP status, attempt number, latency and detail. Delivery history is kept for 30 days. - A delivery times out after 8 seconds. Network errors, timeouts and HTTP 408, 425, 429, 500, 502, 503 and 504 are retried after 30 seconds, 2 minutes and 8 minutes. Other errors aren't retried. - After 10 failed deliveries in a row, the endpoint is disabled. Fix it and choose **Enable**. There is no edit form yet: to change an endpoint, delete it and add it again. ## Deploy webhooks A deploy webhook calls your pipeline when an AI CodeOps pull request is merged from the console. 1. Open **Release → Deployments** and choose **Deploy targets**. 2. For each project, enter a **Deploy webhook URL**, an **Environment** and an optional **Signing secret**. 3. Save. On merge, AI CodeOps sends: ```json { "event": "pr_merged", "workspaceID": "wrk_01JA2B3C4D5E6F7G8H9J0K1M2N", "projectID": "prj_01JA2B3C4D5E6F7G8H9J0K1M2R", "repo": "acme/api", "prNumber": 42, "prUrl": "https://github.com/acme/api/pull/42" } ``` With a signing secret it adds `X-CodeOps-Signature: sha256=…`, computed the same way as above. The URL must be public HTTPS. A [workspace policy](https://aicodeops.dev/docs/policy-engine) `release.deploy` rule can block automatic deploys to an environment. ## Next steps - [API](https://aicodeops.dev/docs/api) - [Policy rules reference](https://aicodeops.dev/docs/policy-engine) - [Approvals and policies](https://aicodeops.dev/docs/approvals-and-policies) ## Frequently asked questions ### Do I need to add a webhook to my Git repository? No. AI CodeOps doesn't receive webhooks from Git hosts and doesn't register any on your repositories. It talks to your Git host with your connection's token. ### Are notification payloads signed? Generic webhooks with a signing secret are signed with HMAC-SHA256 in the X-CodeOps-Signature header. Slack, Discord and Teams messages aren't signed. ### What happens if my endpoint is down? Failed deliveries are retried after 30 seconds, 2 minutes and 8 minutes. After 10 failures in a row the endpoint is disabled. --- # MCP servers > Connect remote MCP servers so AI CodeOps agents can call their tools: add a server, keep its headers encrypted, and limit tools per agent and by policy. Source: https://aicodeops.dev/docs/mcp-servers · Last updated: 2026-10-18 The Model Context Protocol (MCP) lets an AI agent call tools on another service, such as an issue tracker or a documentation search. In AI CodeOps, you connect MCP servers to your workspace and the agents in your sessions can use their tools. Here AI CodeOps is the client: it connects **to** MCP servers you add. To use AI CodeOps from your own coding assistant instead, see [the AI CodeOps MCP server](https://aicodeops.dev/docs/mcp-server). MCP support is in beta. ## Remote and local servers | Type | What you enter | Used by sessions? | | ------------------------- | ----------------------------------- | -------------------------------------------------- | | **Remote (HTTP/SSE URL)** | The server's URL and HTTP headers | Yes | | **Local (stdio command)** | A command and environment variables | No. It is registered, but sessions don't start it. | Sessions run on the platform, not on your computer, so they can't start a program on your machine. Use a remote server for anything your agents should call. Remote servers must: - be on a public HTTPS address (private networks and `localhost` are refused); - speak the MCP **Streamable HTTP** transport (JSON-RPC over POST, with a JSON or event-stream response); - accept authentication in static headers, such as a bearer token. Servers that need an OAuth sign-in aren't supported yet, and neither is the older SSE-only transport. ## Add a server 1. Open **Configure → MCP Servers** and choose **Add MCP server**. 2. Enter a **Name**, for example "GitHub". AI CodeOps makes the server's ID from it, in lower case with dashes: "GitHub" becomes `github`, "Docs Search" becomes `docs-search`. Tool names and policy rules use this ID. 3. Choose **Remote (HTTP/SSE URL)** and enter the **Server URL**. 4. Under **Headers**, add one `KEY=value` per line, for example: ```text Authorization=Bearer ``` 5. Choose **Save MCP server**. The server appears under **Servers** with **Disable** and **Remove**. There is no edit form yet: to change a server, remove it and add it again. Managing MCP servers needs the MCP-manage permission: owners, admins and DevOps admins by default. ## How secrets are stored Headers (remote) and environment variables (local) are encrypted at rest with AES-256-GCM. They are never sent back to the browser; the list shows only which keys are set, such as "1 header: Authorization". They are decrypted only when a session connects to the server. Server creation, changes and removal are recorded in the [audit log](https://aicodeops.dev/docs/audit-logs). ## How agents get the tools When a session starts, AI CodeOps connects to each enabled remote server and lists its tools. A server that can't be reached is skipped, and the session runs without its tools. - Tools are named `__`, for example `github__create_issue`. - A session can offer up to 32 MCP tools in total. - In each agent step, an agent can make up to 6 rounds of tool calls. - Each call times out after 30 seconds, and long results are shortened. You can narrow which tools reach the agents in two ways. ### Per agent On **Configure → Agents**, a custom agent has a field **MCP tools allowed**. Enter servers, tools or `server__tool` names, comma-separated. Leave it blank to allow all. ### By workspace policy A [policy rule](https://aicodeops.dev/docs/policy-engine) on the `mcp.invoke` action matches `server/tool`. A tool the policy doesn't allow is never offered to the agents. For example, to keep every delete tool on the GitHub server away from your sessions: ```json { "id": "no-repo-deletes", "action": "mcp.invoke", "resource": "github/delete_*", "decision": "deny" } ``` `mcp.invoke` rules can use `allow` or `deny`, not `ask`. With the **None** trust posture, MCP tools are denied unless a rule allows them. ## Troubleshooting If a session doesn't use a server's tools: - Check the server is enabled and is a **Remote** server. - Check the URL is public HTTPS and the server supports Streamable HTTP, not only SSE. - Check the headers: an expired token makes the server refuse the connection. - Check the custom agent's **MCP tools allowed** field and your workspace policy. ## Next steps - [Agents and workflows](https://aicodeops.dev/docs/agents) - [Policy rules reference](https://aicodeops.dev/docs/policy-engine) - [Dependency audit](https://aicodeops.dev/docs/dependency-audit) ## Frequently asked questions ### Is AI CodeOps itself an MCP server? Yes, separately from this page. Its MCP server lets Claude Code, Cursor or another MCP client use your workspace; see the AI CodeOps MCP server guide. This page is about the other direction, the servers your sessions connect to. ### Do sessions start local (stdio) MCP servers? No. You can register a local server, but sessions only connect to remote servers over HTTPS. ### Can I see a header after saving it? No. Headers and environment variables are encrypted at rest and never shown again. The list only shows which keys are set. --- # The AI CodeOps MCP server > Connect Claude Code, Cursor or any MCP client to AI CodeOps: start sessions, read findings, check the release gate and fetch evidence packs from your editor. Source: https://aicodeops.dev/docs/mcp-server · Last updated: 2026-10-21 AI CodeOps runs a remote [MCP](https://modelcontextprotocol.io) server, so the AI coding tool you already use can work with your workspace: start a session from your editor, follow it, check whether a pull request may ship, and pull the signed record of a change. It is separate from [MCP servers](https://aicodeops.dev/docs/mcp-servers), where AI CodeOps connects to other servers so the agents in your sessions can use their tools. Here, AI CodeOps is the server. ## Connect You need a workspace API key. Create one under **Configure → API Keys**; it starts with `sk-` and is shown once. See [API keys](https://aicodeops.dev/docs/api#workspace-api-keys). **Claude Code:** ```bash claude mcp add --transport http aicodeops https://console.aicodeops.dev/mcp \ --header "Authorization: Bearer sk-..." ``` Then run `/mcp` in Claude Code: `aicodeops` is listed as connected, with its six tools. **Cursor**, in `.cursor/mcp.json`: ```json { "mcpServers": { "aicodeops": { "url": "https://console.aicodeops.dev/mcp", "headers": { "Authorization": "Bearer sk-..." } } } } ``` **Any other client:** the address is `https://console.aicodeops.dev/mcp`, the transport is Streamable HTTP, and the key goes in the `Authorization: Bearer` header. Keep the key out of files you commit: most clients read it from an environment variable. ## Tools | Tool | What it does | Key needs | | -------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------- | | `list_projects` | Lists the workspace's projects and their repositories. | `workspace:read` | | `start_session` | Starts a session on a project with a task. Optional: a `workflow` (default `plan-build-review-test`) and an `agent`. | `workflow_run:manage` | | `get_session` | A session's status, its steps, the pull request it opened and its change. | `workspace:read` | | `check_release_gate` | Whether a pull request or commit may ship, with the reasons. The same check as [the API](https://aicodeops.dev/docs/api#release-gate-check). | `workspace:read` | | `list_findings` | Security and quality findings, filtered by `severity` or `category`. | `workspace:read` | | `get_evidence_pack` | The signed [evidence pack](https://aicodeops.dev/docs/evidence-packs) of a change, by `changeID` or by the session that started it. | `workspace:audit.read` | A tool the key may not use answers with an error that says why, and the other tools keep working. `start_session` and `get_evidence_pack` also need their permission listed on the key's scope (see below). ## What a tool can do Each tool acts as the key's creator, through the same checks as the console: - **Roles:** a member who can't start sessions in the console can't start them here. A viewer's key can read, nothing more. - **Key scope:** any key can use the four read tools. `start_session` and `get_evidence_pack` work only for a key whose scope lists their permission: choose **Scope** on the key under **Configure → API Keys** and tick **Start sessions from the MCP server (/mcp)** or **Evidence packs from the MCP server (/mcp)**. A key with no scope can't start sessions here, so keys already made for CI or the model gateway don't gain that by themselves. Key scoping depends on your plan. - **Spend:** sessions count against the workspace's budget and the agent's work-in-progress limit, as they do in the console. - **Audit:** a session records who started it, the key's creator. Exporting an evidence pack is recorded in the [audit log](https://aicodeops.dev/docs/audit-logs). A session started here opens its pull request like any other, so your approvals and the release gate still apply before it merges. ## Limits - 120 requests a minute from one address. - Stateless: each request stands alone. The server doesn't send notifications or open an event stream. - Workspace API keys only. OAuth sign-in isn't supported yet. ## Frequently asked questions ### How does the MCP server sign in? With a workspace API key sent as a Bearer token. The key acts as the member who created it, with that member's current role. OAuth sign-in isn't supported yet. ### Can the MCP server change my code directly? No. start_session starts a session, and the session works the way it does from the console, through a pull request that your approvals and release gate still apply to. Every other tool only reads. ### Which clients work? Any MCP client that supports the Streamable HTTP transport and a custom header, including Claude Code and Cursor. --- # Troubleshooting > Fixes for common AI CodeOps problems: Git connections, sessions that stop on allowance or budget, pull requests that won't open, missing pages and sign-in. Source: https://aicodeops.dev/docs/troubleshooting Find the message you're seeing below. If it isn't here, ask the Help assistant in the console first: it can open a support ticket with your conversation attached. ## Git connections **"Token rejected — check the URL and key."** The Git host refused the token. Check that the instance URL is your server's base address, that the token hasn't expired, and that it has the scopes listed in the guide for your host: [GitHub](https://aicodeops.dev/docs/git/github), [GitLab](https://aicodeops.dev/docs/git/gitlab), [Bitbucket](https://aicodeops.dev/docs/git/bitbucket), [Gitea](https://aicodeops.dev/docs/git/gitea), [Forgejo](https://aicodeops.dev/docs/git/forgejo). **"… sign-in isn't set up on this server"** OAuth isn't available for that host or server. Connect with a personal access token instead. **"Use the public https address of your Git server"** AI CodeOps runs in the cloud and can only reach Git servers on the public internet over https. Private addresses, `localhost` and URLs with a query string are refused. **A connection shows Active, but repositories fail to load** The token may have been revoked on the Git host; the status only tracks the expiry date. Disconnect under **Configure → Settings → Git Providers** and connect again. ## Sessions **"Connect a model provider to run this session"** The workspace has no provider of its own and the platform's models aren't available to it. Add a provider key on the Dashboard under **Bring Your Own Key**, or contact support. **"… models aren't set up on this platform yet"** That tier isn't offered right now. Start the session on Economy or Auto, or use your own provider key. **A session stopped because an allowance was used up** The tier's monthly allowance ran out and the workspace has no credits. Use another tier, add credits on the **Billing** page, connect your own key, or wait for the reset on the 1st of the month (UTC). See [Models and tiers](https://aicodeops.dev/docs/models). **"Over budget" or "Stopped over budget"** The workspace budget, or the cap for that workflow, was reached. An owner, admin or billing admin can raise it under **Configure → Billing → Cost budget**. See [Cost controls](https://aicodeops.dev/docs/cost-controls). **A session failed on a provider error** If it ran on your own key, check that the key is valid and has quota with that provider. **"No projects yet — AI-generated code must live in a project."** Create a project first under **Plan → Projects**. See [Projects](https://aicodeops.dev/docs/projects). **A session is waiting before it starts** A workspace policy requires approval to start that workflow. It waits on **Review & Gate → Approvals**; if the approval is rejected or expires, the session is cancelled. ## Pull requests **"This change is awaiting human approval."** Approve it on **Review & Gate → Approvals** or with **Accept changes** on the session page. If you launched the session, someone else has to approve it. **"This change isn't release-ready: …"** The quality gate found failing tests, open high or critical findings, or an AI review that didn't finish. Triage the findings or re-run the session. See [Quality gates](https://aicodeops.dev/docs/quality-gates). **"This change was rejected in review"** Start a follow-up from the session page to revise it. **"The release check couldn't run just now."** A temporary problem. Try again in a moment. **The Create Pull Request button is locked** The label says why: **Connect git to open PR** (connect an account for the repository's host) or **Add a repository to open PR** (add a repository URL to the project). ## Access and sign-in **A page or button is missing** Your role may not allow it. Ask a workspace owner or admin. See [Members and roles](https://aicodeops.dev/docs/members). **"Someone else needs to approve a change from a session you launched."** The two-person rule: another member who can approve has to decide. **An invitation link says it has expired or was already used** Invitation links last 7 days and work once. Ask an admin to send a new one, and sign in with the address it was sent to. **Signed out unexpectedly** Sign-ins expire after a while; sign in again. If your account was suspended, you'll see a notice. **SSO sign-in fails** Your email domain must match the SSO connection's verified domain, and the connection must be active. Ask your administrator to check **Configure → Settings → Single sign-on**. See [Single sign-on](https://aicodeops.dev/docs/sso). ## Still stuck? Ask the Help assistant in the console, then choose **Contact support**. A support engineer replies by email and in the Help panel. You can also reach us through the [contact page](https://aicodeops.dev/contact). --- # Frequently asked questions > Short answers about AI CodeOps: what it does, what it costs in the open beta, which Git hosts and models it supports, and how it handles your code and data. Source: https://aicodeops.dev/docs/faq · Last updated: 2026-10-18 Short answers to the questions people ask most. Each links to the page with the details. ## Product AI CodeOps runs in your browser. Agents plan, build, review and test a change in a session; you review it and approve it before a pull request is opened. Start with the [Quickstart](https://aicodeops.dev/docs/quickstart), then read about [Sessions](https://aicodeops.dev/docs/sessions) and [Quality gates](https://aicodeops.dev/docs/quality-gates). ## Cost The open beta is free, with a monthly token allowance on the platform's models. See [Pricing](https://aicodeops.dev/pricing), [Models and tiers](https://aicodeops.dev/docs/models) and [Cost controls](https://aicodeops.dev/docs/cost-controls). ## Security and data Your code is read through the Git account you connect, tests run in isolated sandboxes, and secrets are encrypted at rest. See [Security](https://aicodeops.dev/security), the [Trust page](https://aicodeops.dev/trust) and [Data retention and deletion](https://aicodeops.dev/docs/data-retention). ## Enterprise SSO, custom roles and self-hosted deployment are Enterprise options. See [Single sign-on](https://aicodeops.dev/docs/sso), [Self-hosted deployment](https://aicodeops.dev/docs/self-hosted) and the [Enterprise page](https://aicodeops.dev/enterprise). ## Still stuck? Try [Troubleshooting](https://aicodeops.dev/docs/troubleshooting), or [contact support](https://aicodeops.dev/docs/contact-support). ## Frequently asked questions ### What is AI CodeOps? A browser-based platform where AI agents plan, build, review and test code changes, and a change only becomes a pull request after its quality gates pass and a person approves it. ### Does AI CodeOps cost anything? Not during the open beta. It is free to use, with a monthly allowance of AI tokens on the platform's models. Nothing is charged unless you choose a plan. ### Do I need to install anything? No. AI CodeOps runs in the browser and sessions run on the platform. There is no CLI or desktop app. ### Which Git hosts does it work with? GitHub, GitLab, Bitbucket, Gitea and Forgejo, including self-managed GitLab, Gitea and Forgejo servers reachable over HTTPS. ### Can I use my own model provider key? Yes. Anthropic, OpenAI, Moonshot (Kimi), Z.ai (GLM), DeepSeek, Groq, OpenRouter and Ollama Cloud keys can run sessions. Your provider bills you for them. ### Will AI CodeOps push code without a person checking it? No. Every code change waits for an approved review and passing quality gates before AI CodeOps opens a pull request. ### Where do sessions run? On the platform, not on your computer. When a session runs your tests, it runs them in an isolated sandbox container with restricted network access. ### Is my code used to train AI models? AI CodeOps doesn't use your content to train or fine-tune AI models. The model provider that runs a session processes it under its own API terms. ### Where is my data stored? AI CodeOps's servers and database are in the United States. Service providers and their regions are listed on the Trust page. ### Is AI CodeOps SOC 2 or ISO 27001 certified? Not yet. The Trust page lists the controls in place today and the subprocessors used. ### Does AI CodeOps support single sign-on? Yes, on the Enterprise plan, with SAML 2.0 or OpenID Connect. ### Can I run AI CodeOps on my own infrastructure? Only as an Enterprise option, on request. Self-hosted Enterprise installs run on your Kubernetes cluster. ### How do I stop AI spend from running away? Set a workspace cost budget with a hard limit, and per-workflow caps if you need them. Sessions stop once spend passes the hard limit. ### How do I get help? Choose Help in any workspace to ask the Help assistant or open a ticket. Not signed in? Email support@aicodeops.dev. --- # Contact support > Get help with AI CodeOps: ask the in-console Help assistant, open a support ticket, email the team, check the status page, or report a security issue. Source: https://aicodeops.dev/docs/contact-support · Last updated: 2026-10-18 There are three ways to get help: ask the Help assistant, open a ticket with the support team, or email us. For outages, check the status page first. ## Ask the Help assistant Every workspace has a **Help** button in the bottom-right corner. 1. Choose **Help**. The **Ask** tab opens. 2. Type your question, for example "How do I add a teammate?", and choose **Ask**. 3. Ask follow-up questions in the same conversation, or choose **New conversation** to start over. The assistant answers from the AI CodeOps Help Center and knows your workspace's plan and remaining allowance. It can't change anything in your workspace. If it can't help, for example with billing disputes, account access or bugs, it offers **Contact support with this conversation**. The assistant uses an AI model: your workspace's own provider if you've connected one, otherwise the platform's Economy tier within your allowance. You can ask up to 30 questions in 10 minutes. ## Open a support ticket 1. Choose **Help**, then the **Contact support** tab. 2. Enter a **Subject** and describe **What do you need help with?** 3. Leave **Attach my conversation with the Help assistant** ticked if you talked to the assistant first; it saves you repeating yourself. 4. Choose **Send to support**. A person from support replies to your account's email address. You can open up to 5 tickets an hour. ### Follow a ticket Open **Help → My tickets** to see your tickets in this workspace and their status: | Status | Meaning | | ------------------- | ----------------------------------------- | | Waiting for support | Your ticket or latest message is with us. | | Answered | Support replied. Check your email. | | Closed | The ticket is done. | Add a message to any ticket with **Add a message** and **Send**. Replying reopens an answered or closed ticket. ## Email Not signed in, or can't reach your workspace? Email [support@aicodeops.dev](mailto:support@aicodeops.dev). For legal notices and privacy requests, email [legal@aicodeops.dev](mailto:legal@aicodeops.dev). Both are listed on the [Contact page](https://aicodeops.dev/contact). For an Enterprise plan, SSO or a self-hosted Enterprise deployment, use the contact form on the [Enterprise page](https://aicodeops.dev/enterprise). ## Check service status The [status page](https://aicodeops.dev/status) shows the live health of the platform's components, such as the database, Redis, secret encryption and the event bus, and the result of a regular synthetic check. It refreshes every 30 seconds. During the open beta there is no SLA. ## Report a security issue Email [support@aicodeops.dev](mailto:support@aicodeops.dev) with "Security" in the subject. Please don't test against other customers' data. We acknowledge your report and keep you updated while we fix it. The contact is also published at `/.well-known/security.txt`. Our practices are described on the [Security page](https://aicodeops.dev/security). ## Before you write Many problems have a quick fix in [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) or the [FAQ](https://aicodeops.dev/docs/faq). If you write to us, include: - the workspace name; - the session or page where it happened, with a link if you have one; - what you expected and what you saw, including any error message. ## Next steps - [Troubleshooting](https://aicodeops.dev/docs/troubleshooting) - [Frequently asked questions](https://aicodeops.dev/docs/faq) - [Status](https://aicodeops.dev/status) ## Frequently asked questions ### How quickly does support reply? There is no guaranteed response time during the open beta. A person from support replies by email, and the reply also appears under My tickets. ### Does asking the Help assistant use my allowance? Yes, when it runs on the platform's models. If your workspace has its own provider key, it uses that instead. ### How do I report a security vulnerability? Email support@aicodeops.dev with "Security" in the subject. Don't test against other customers' data.