Setting up agent tasks

Agent tasks are enabled per project, not per account. Everything on this page happens on the Agent tab of the project's settings. You need the "Project settings" permission to open it; if you cannot, ask whoever administers your workspace.

Turning agent tasks on

1. Open the project. From the Projects page, click "Settings" on the project card, or click "Project Settings" at the bottom of the console sidebar.
2. Click the "Agent" tab.
3. Tick "Enable agent tasks". This starts a poller inside every staging and development instance of the project, ready to pick work up.
4. Choose a CLI and paste its credential, as described in the next sections.
5. Click "Save Changes" at the top of the page.

You can also reach this tab from the Agent Tasks page: while agent tasks are not set up, it shows "Agent tasks are not set up yet" with an "Open project settings" button.

Choosing a CLI

1. Under "Agent CLI", pick which coding CLI plans and executes tasks on this project: Claude Code, Gemini CLI, Codex CLI or Grok Build.
2. Optionally, enter a "Model": a model alias or full model name for that CLI. Leave it blank to use the CLI's default.

Each CLI 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 stays masked in its field, so switching away and back does not ask for the secret again.

Connecting Claude Code

Claude Code has one sign-in mode here, and it needs a Claude subscription.

1. On your own machine, run claude setup-token.
2. Paste the token into "Claude Code Token".
3. Click "Save Changes".

Connecting Gemini CLI, Codex CLI or Grok Build

These three can each run two ways, and the difference decides who pays.

1. Under "How the agent signs in", pick your own subscription ("My Gemini subscription", "My ChatGPT subscription" or "My Grok subscription") or "API key (billed per token)".
2. For your own subscription, sign in to the CLI on your own machine (for Codex run codex login, for Grok Build run grok login), then paste the whole contents of its cached sign-in file into the sign-in file box:
   • Gemini CLI: ~/.gemini/oauth_creds.json into "Gemini sign-in file".
   • Codex CLI: ~/.codex/auth.json into "Codex sign-in file".
   • Grok Build: ~/.grok/auth.json into "Grok Build sign-in file".
3. For an API key, create one with the provider and paste it into "Gemini API Key" (from Google AI Studio), "OpenAI API Key" (from the OpenAI platform dashboard) or "xAI API Key" (from console.x.ai). Runs are billed to that key by the provider.
4. For a paid Gemini Code Assist licence only, enter its project id in "Google Cloud project (optional)". Leave it blank for a personal Google account.
5. Click "Save Changes".

With a sign-in file, the agent refreshes it as it runs and sends the refreshed copy back, so you should not have to paste it again.

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.

Letting plans run without review (auto-execute)

1. On the Agent tab, tick "Auto-execute plans".
2. Click "Save Changes".

New tasks on this project then 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. Each task's "Auto-execute" checkbox in the "New Agent Task" form starts from this setting and can be changed per task.

The "Auto-execute plans" option only appears if your role includes the "Approve plans" permission.

Adding skills

Skills record house conventions the agent should follow: how you name things, how you write views, how you test. They are stored in the project's own S3 bucket, so the Skills section asks you to configure S3 on the Storage tab first if it is not set up.

1. On the Agent tab, scroll to "Skills".
2. Click "Add skill" and choose one or more files: a Markdown (.md) file, or a .zip of a skill folder with a SKILL.md inside.
3. Click "Upload".
4. Optionally, tick "Always on" next to a skill so every task gets it, whether or not it is ticked when the task is created.

Uploads, "Always on" and deletions take effect straight away; they do not need "Save Changes". To remove a skill, click "Delete" next to it. Tasks already running keep the copy they were given.

When you create a task, you tick which skills it uses. 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.

Checking your agent hours from the project

Below the options, the tab shows "Agent hours available" for your account, with a "Manage" link to the Billing tab of Settings. When you run out, it says so and offers "Top up agent hours", or "Ask the workspace owner to top up." if you cannot reach billing yourself. Once the project has run tasks, "Consumption to date" shows its task count, total tokens and agent time. The "Open Agent Tasks" button at the bottom takes you to the project's task list.

Related: What agent tasks are, Running a task and reviewing the result, Agent time and top-ups, S3 storage, uploads and bulk backup actions.

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