Development workbench
Let Developer and QA agents work on the company's repositories in an isolated environment, with pull requests under human control.
The development workbench is a company service, running on a separate machine, where Developer and QA agents open the granted repositories, each task in its own isolated copy. The Team Connect server never runs repository code.
What agents do on the workbench
- Developer: opens the repository on the task's own branch (always prefixed with
agent/), reads and changes files, runs commands and tests, commits, pushes the branch and opens the pull request. It also continues a PR it opened itself when changes are requested. - QA: opens a pull request read-only, runs the tests and comments the result on the PR.
- Commands run in an isolated container, with no network access by default, and with time, CPU, memory and disk limits.
- Agents never merge, never push straight to the main branch and never approve a PR. Merging is always done by a person.
- Git server credentials never enter the isolated environment and never reach the model.
Each step shows up in the task panel (repository, branch, PR link and last command) and in the audit log.
Before you start
- Whoever runs your infrastructure installs the workbench service on a separate machine, with git and Docker, and sets a shared secret. On hosted Team Connect, the workbench also runs on the company's infrastructure and needs a public
httpsaddress. - Register the company's Git server (see below).
- Have at least one LLM connection: Developer and QA use the managed brain.
Connect the workbench
- In the sidebar, open Integrations, Company tab.
- On the Development workbench card, click Configure.
- Fill in Workbench address and Shared secret. The secret is encrypted and never shown again.
- Tick Turn on the workbench for agents.
- Click Save and then Test connection.
When everything is right, the status shows Responding, how many repositories are open, the free disk space and, when agents can run commands, isolated commands available.
Approval before the pull request
Tick Ask the task's requester for approval before opening a pull request so the Developer asks before opening each PR. The person approves or declines in the agent's Tasks panel or in the chat. With the option off, the agent opens the PR on its own; merging is still done by a person.
Coding engines
Under Coding engines, choose which engines the Developer may use for a heavy step: Aider (any provider), Claude Code (needs an Anthropic connection) and Codex CLI (needs an OpenAI-compatible connection). The engine runs isolated in the task's copy and only works with API keys: the company's LLM key never enters the isolated environment. Each agent's default engine is set in the agent form, under Default coding engine.
Supported Git servers
On the Git servers card, click Configure and then New Git connection. In Service, choose:
| Service | Credential |
|---|---|
| GitHub (GitHub App) | App ID, Installation ID and private key |
| GitHub (token), GitHub Enterprise Server, GitBucket | Access token |
| GitLab.com and self-managed GitLab | Project or group access token |
| Bitbucket Cloud | Workspace or repository access token |
| Gitea / Forgejo and Codeberg | Access token |
The screen shows which permissions each credential needs. When you click Save connection, Team Connect checks the credential with the Git server. Then edit each agent and tick the Repositories granted to it (none are granted by default).
Events and automatic review
On each Git connection, Events and automatic review lets you receive PR and CI notices in office channels and have a Code reviewer agent review PRs on its own (Review when a PR is opened or Review when someone mentions the reviewer in a PR comment). Click Enable events and register the address and secret shown on the Git server.
Privacy (LGPD)
What agents read in repositories goes to the chosen LLM provider and stays in transcripts for the retention period. Repositories can contain personal data: grant only what is needed.