All articles

Getting Started

What is CICDoo Getting started: the onboarding wizard The Dashboard and Infrastructure Map

Concepts

Production, staging and development stages Domains, subdomains and SSL Odoo versions and editions (Community vs Enterprise) Workspaces and team collaboration

Servers

Adding a server Server domains and DNS Using a load balancer Server actions: deploy, logs and charts

Projects & Git

Creating a project Connecting GitHub Connecting GitLab Branches and instances

Instances & Console

Creating an instance Restarting, stopping and removing an instance Merging branches between stages Web IDE and remote access Instance settings explained Deployments and the job queue

Agent Tasks

What agent tasks are Setting up agent tasks Running a task and reviewing the result Agent time and top-ups

Monitoring & Backups

Monitoring your instance Backups and restore Alert notifications (email and SMS)

Workspaces & Permissions

Inviting workspace members Member permissions and resource access A member cannot see or use a resource

Account & Security

Two-factor authentication (2FA) Profile and integrations settings Passwords and account recovery

Billing & Plans

Plans and pricing Upgrading and managing your subscription If a project subscription goes unpaid The channel partner program

Support & Tickets

Opening a support ticket Getting help from the CICDoo team

Troubleshooting

Troubleshooting: cannot connect a server Troubleshooting: a deployment failed Troubleshooting: git push fails with 403 after moving a repository Troubleshooting: my instance is down or slow Troubleshooting: domain or SSL problems

Agent Tasks

Setting up agent tasks

Turning agent tasks on for a project, choosing a coding CLI, connecting your own account to it, and teaching the agent your house conventions with skills.

Turning it on

Agent tasks are enabled per project, not per account. Open the project, go to Settings, then the Agent tab, and tick Enable agent tasks. That starts a poller inside every staging and development instance of the project, ready to pick work up.

You need the project settings permission to see and change this tab. If you cannot open it, ask whoever administers your workspace.

Choosing a CLI

Under Agent CLI, pick which coding CLI plans and executes tasks on this project:

  • Claude Code
  • Gemini CLI
  • Codex CLI

Each signs in with its own credential and runs on your own account with that provider. CICDoo does not resell model access; the agent uses the subscription or key you supply, and runs count against your quota there.

You can switch CLI later. A credential you have already stored keeps its mask, so switching away and back does not ask for the secret again.

Connecting your account

How you connect depends on the CLI, and the difference decides who pays.

Claude Code

Run claude setup-token on your own machine, which needs a Claude subscription, and paste the token into Claude Code Token. This is the only mode Claude Code offers here.

Gemini CLI and Codex CLI

Both can run two ways, chosen under How the agent signs in:

  • Your own subscription. Sign in to the CLI on your own machine, then paste the whole contents of its cached sign-in file: ~/.gemini/oauth_creds.json for Gemini, ~/.codex/auth.json for Codex. The agent refreshes it as it runs and sends the refreshed copy back, so you should not have to do this again.
  • API key, billed per token. Create a key in Google AI Studio or the OpenAI platform dashboard and paste it in. Runs are billed to that key by the provider.

A paid Gemini Code Assist licence also needs its Google Cloud project id. Leave that blank for a personal Google account.

Read this before pasting a credential

The credential is stored on the platform and sent to your instance containers so the agent can authenticate. Anyone with shell or IDE access to those containers can read it.

A sign-in file is a stronger thing to hand over than an API key. It is your account session, not a scoped credential: it cannot be revoked on its own, and it is what the CLI would use if someone ran it by hand inside the container. Providers also aim these plans at interactive use, and OpenAI recommends an API key for automated workflows, so check your plan terms before pointing an agent at a personal subscription.

If that is a concern for your setup, use API key mode where the provider offers it: a key can be scoped and revoked on its own.

Optional settings

  • Model. A model alias or full model name for the CLI you picked. Leave blank to use its default.
  • Auto-execute plans. New tasks on this project skip the review step: a successful plan is approved automatically, then implemented and pushed with nobody reading it first. A plan the agent reports as blocked still waits for you, and so does every plan on the production instance. You can change this per task, and setting it needs the plan-approval permission.

Skills: teaching it your conventions

The Skills section on the same tab is where you record house conventions the agent should follow: how you name things, how you write views, how you test.

Upload a Markdown file, or a .zip of a skill folder with a SKILL.md inside. You pick which skills a task uses when you create it, and a skill can be marked always-on so every task gets it. Skills live in your project's own storage bucket and are installed into the container for the tasks that use them.

This is the cheapest way to improve results. An agent that knows your module layout and your testing convention produces plans you have to correct less often.

Next steps

For what an agent task is and the rules around production, see What agent tasks are. To create and review your first one, see Running a task and reviewing the result.

If you get stuck, open a support ticket from the Tickets page or the chat widget.

Previous What agent tasks are Next Running a task and reviewing the result

Still stuck? Open a ticket from the app or talk to an engineer.