Filling in tool parameters

By the end of this page you will know what to type into any code tool’s settings, and what to leave alone.

Prerequisites

A code tool attached to an agent — see Attach tools.
The Code & Execution configurations created.
Admin or Developer role.

The three kinds of parameter

When you attach a code tool, the Studio shows its parameters. Every one of them falls into one of three kinds, and recognising which answers “do I type something here?” every time.

Kind	How to recognise it	What you do
Bind it to a configuration	The name starts with an underscore, or it is `token`	Pick a configuration from the dropdown. Never type the value.
Leave it empty — the agent fills it	`path`, `query`, `content`, `message`, `title`, `search`…	Nothing. The agent decides at run time.
Pin it if you want to	`repo_url`, `branch`, `working_dir`, `timeout_seconds`…	Optional. A value here takes the choice away from the agent.

Bind it to a configuration

Six parameters connect a tool to the rules it should follow. Each one offers a dropdown filtered to the right kind of configuration, so you pick by name.

Parameter	Takes	Which tools have it
`_workspace`	A Code Workspace	Every file and git tool
`_sandbox`	A Command Sandbox	Every tool that runs a command
`_toolchain`	A Code Toolchain	Build, test, lint, type-check, security scan, command, quality gate
`_quality_gate`	A Code Quality Gate	`code_quality_gate`
`_spec_standards`	Specification Standards	`spec_write`, `spec_validate`
`token`	The secret field of an Azure DevOps or GitHub Integration	Clone, push, pull request

A code tool's workspace parameter with its configuration dropdown open, filtered to Code Workspace configurations

An empty dropdown means you have not created a configuration of that kind yet. Create it first — see Code & Execution.

What happens if you leave one empty

Left empty	Result
`_sandbox`	Refuses — “Command execution is not configured for this project”
`_toolchain`	Refuses — “No build command is configured for this project”
`_quality_gate`	Runs with defaults: build and tests required, no failures tolerated, coverage off
`_spec_standards`	Specifications are stored unvalidated
`token`	Refuses on clone, push and pull request
`_workspace`	Runs anyway — see the warning below

🚨

An unbound _workspace is the dangerous one. It does not fail. The tool runs with platform defaults instead, so your protected branches and protected files are not applied — the agent is working to our rules rather than yours. Bind it on every file and git tool, even when the defaults look right.

Leave it empty — the agent fills it

Most parameters describe what the agent is doing right now, and it supplies them: which file to read, what to search for, what to write, what to call a branch, what a commit message says.

Typing a value into one of these does not help the agent and usually breaks it. A pinned path means every read returns the same file.

The fastest way to get this right

For any code tool: bind every underscore parameter and token, leave everything else blank. That is a working agent.

A saved code tool binding showing configuration references on the underscore parameters

Common issues

The configuration dropdown is empty — No configuration of that kind exists yet.
A tool refuses, naming a configuration — That binding is missing. The message says which.
The agent keeps working on the wrong file — Something agent-filled has been pinned. Clear it.
Your rules are not being applied, but nothing fails — _workspace is unbound.
You cannot find your access token in the dropdown — The token parameter lists Azure DevOps and GitHub Integrations, not Code & Execution configurations. Create one under Integrations.