Documentation / Code and addons
Coding Agents
Let an AI coding agent change your addons in a sandbox copy of your Odoo, then review its pull request.
A coding agent is an AI that works on one of your addon repositories for you. You describe the change, and the agent edits the code, tries it out in a sandbox copy of your Odoo and opens a pull request once you approve its push. You follow along in the session, answer its questions and decide what it may do.
Coding agents are in early access and are being rolled out team by team. If you don't see Agent Sessions under Developer in the panel menu, they aren't enabled for your team yet. Get in touch and we'll switch them on.
How it works #
- Each session gets a sandbox: a neutralized copy of the Odoo you started it from, created on that Odoo's server for copies, or on its own server if none is set. Sandboxes do not count towards your plan's copy limit.
- The agent runs next to the sandbox on your server. Its checkout, its conversation and the Odoo data stay on your server.
- The agent runs on your own AI provider key and your bill with that provider. The cost shown in the panel is an estimate.
- Nothing leaves the sandbox without you: every
git pushasks for your approval, whatever permission mode the session runs in.
Before you start #
Add your API key #
A team owner or admin adds the key once:
- Open the team menu and choose Team profile.
- In AI / Coding agents, choose the Provider:
- Anthropic runs Claude on your Anthropic key.
- OpenRouter and Requesty run Claude and other models, such as GLM, Kimi or DeepSeek, on your key with them. For Requesty, choose the EU or Global region.
- Paste the key and optionally choose a Default model, which every new session starts with.
- Save.
A stored key is never shown again. Paste a new one to replace it, or remove it with the switch below the field.
Prepare the repository #
The agent works on a repository that is added to the Odoo through the calmo.cloud GitHub App, with addons synced for the Odoo's version. The pull request goes to that repository.
Starting a session #
Open the Odoo and its Agent Sessions tab, or open Agent Sessions in the menu and click Start session. Then fill in:
| Field | What it does |
|---|---|
| Title | A name for the session. It also becomes the title of the pull request. |
| Service | Only when starting from the list: the Odoo the sandbox is copied from. Copies and previews cannot be chosen. |
| Repository | The repository the agent works on. |
| Prompt | What the agent should do, up to 10,000 characters. |
| Attachments | Up to 8 files per message, such as screenshots or sample data, 25 MB each. |
| Model | Pick from your provider's list or type any model id. |
| Reasoning effort | From Low (fastest) to Max (deepest reasoning). Levels a model does not support are lowered automatically. |
| Permission mode | How often the agent asks before acting. See below. |
| Branch | Optional. The branch the agent starts from and the pull request targets. Defaults to the repository's branch for the Odoo's version. |
Setting up the sandbox takes a few minutes. The session page then shows the conversation as it happens.
What the agent can do #
Inside its sandbox, the agent can read and change the repository's files, run commands and commit. It can also:
- restart the sandbox Odoo and read its logs
- install and upgrade modules, optionally running their tests
- run SQL and
odoo shellagainst the sandbox database - open the sandbox in a browser, logged in with an admin account of its own; your users and their passwords are not touched
- read the emails the sandbox sent, attachments included, to check that a change emails the right people. This needs the mail catcher on the server.
- share files with you, such as screenshots or exports
Permissions and questions #
The permission mode decides when the agent stops to ask:
| Mode | Behaviour |
|---|---|
| Ask every time | The agent asks before every action that changes something. The default. |
| Auto-accept edits | File edits go through. Other actions still ask. |
| Auto | The agent decides what is safe to run. |
| Plan mode | The agent only reads and plans, without changing anything. |
A request appears in the conversation as Permission requested with Approve and Deny. When the agent needs input, it asks a question with options to pick from or room for your own answer, and waits until you reply. You can change the model, the reasoning effort and the permission mode while the session runs.
The person who started a session gets an in-app notification when the agent needs a decision or a reply, and when the session fails or cannot start.
Getting the changes #
The badge in the session header shows where the changes stand: No changes, Unpushed, Pushed, PR open, Merged or PR closed. When the agent has unpushed commits, click Request push and approve the push. Then click Open pull request. If a pull request for the branch already exists, the session adopts it. Its status follows GitHub from then on.
Click Open sandbox to try the change yourself before you merge.
Ending, resuming and cleaning up #
- A session is Completed when the agent has finished and gone idle. Send another message to resume it with the same conversation and checkout.
- A session that Failed, for example because the agent stopped unexpectedly, can also be resumed with a message as long as its sandbox exists.
- Stop session cancels the session for good: pending approvals are denied and the sandbox is shut down.
- The sandbox of a finished session is deleted after seven days. Remove sandbox deletes it sooner. The conversation stays readable, but the session can no longer be resumed. The panel warns you if the sandbox still holds unpushed work.
The Agent Sessions list shows Active & unfinished sessions by default: those still running or waiting for you, and those whose work has not reached a merged pull request yet. Switch to All sessions for the full history. Sessions are grouped by Odoo, with an estimated cost per group.
Shared Odoos #
On an Odoo shared with your team, starting sessions needs the Developer role. Sessions belong to the team that started them: the hosting team does not see a partner team's sessions, and the other way round.
Webhooks and the API #
- Webhooks tell your system when a session changes status, asks for a decision, opens a pull request or shares files. The Webhooks button on the session list takes team admins there.
- The REST API and AI assistants over MCP can start sessions, reply to them and answer their requests. Both need the Agency plan; in the panel, coding agents work on every plan.