Code & repository tools
By the end of this page you will know what these tools do, what must be true before they run, and which family to reach for.
Prerequisites
- Admin or Developer role.
- The code tools enabled for your environment — see the callout below.
What these tools do
They let an agent take a repository, read it, change it, build and test it, and open a pull request — under rules you set. Twenty-nine tools in four families:
| Family | Tools | What it covers |
|---|---|---|
| Workspace & files | 9 | Clone a repository, then list, read, search, write, patch and delete files |
| Version control | 8 | Status, log, diff, branch, commit, push, pull, open a pull request |
| Build & verify | 7 | Build, test, lint, type-check, security scan, run a command, apply a quality gate |
| Specifications | 5 | Write, read, list, compare and validate a plan or requirement |
Three things must be true before an agent can touch a repository
An executor is connected
With the recommended setup, every file, git and build call runs on your own machine. See Remote Executors.
The configurations exist
The rules these tools follow — where the working copy lives, how the repository builds, which commands may run — live in Code & Execution configurations. The git credential itself is an Integration.
The tools are attached to an agent, and bound to those configurations
Creating a configuration does not connect it to anything. You bind it per tool. See Filling in tool parameters.
Skip any one of these and the tools either do not appear, or appear and refuse to run with a message naming what is missing. They fail closed, never silently.
Where the work actually happens
Most of these tools do not run inside qRaptor. When your Code Workspace says the working copy lives on an executor — the default and the recommendation — every file, git and build call is sent to your own machine, where your SDKs and your network are.
Thirteen tools are the exception and always run inside qRaptor:
| Tools | Why they never leave |
|---|---|
| The 7 Context Graph tools | They query an indexing service, not a working copy |
| The 5 specification tools | Specifications live in the run’s shared context, not on disk |
git_pull_request_create | It calls the provider’s web API. There is no checkout to be near |
No command is hardcoded. dotnet build, npm run build, mvn package and an in-house shell script are the same code path — a string from your own Code Toolchain configuration. That is why a new language needs no platform release.
Common issues
- “Command execution is not configured for this project” — Your Command Sandbox is still set to Disabled, which is where it starts. See Code & Execution.
- “No build command is configured for this project” — No toolchain is bound to that tool, or it has no build command.
- Your branch rules and protected files are ignored — The workspace configuration is not bound on that tool. It does not fail; it falls back to platform defaults.
- A build lands on a machine with no working copy — Several repositories are open and no executor is pinned. Set Pinned executor on the Code Workspace.
- Everything refuses and no message names a configuration — Check an executor is online. With the working copy on an executor, every file, git and build call depends on one.