Contents
Getting started
Using Codepanion
Connecting your tools
Label each database connection, each code snapshot, and each log source with an environment (qa, staging, prod), pin an investigation to one, and every tool defaults to that environment. A QA engineer can point an investigation at the QA build's source, the QA database, and the QA logs in the same conversation, without prod data bleeding in.
An environment is a first-class investigation context. Pick one from the environment picker at the top of an investigation to pin it. Every tool then defaults to that environment's code, data, and logs; the agent can still name another environment on a call when you ask it to, and the audit log records which environment each call actually used. Leave it on All Environments and the agent uses the default for each, or scopes per request as you ask.
The environments list
Settings → Environments shows every label your team uses. You don't have to set them up in advance: a label appears here automatically the first time you push code or connect a database under it. You can also create one ahead of time: a label plus an optional display name, so prod reads as "Production" wherever the environment is shown.
A label is lowercase letters, digits and hyphens, up to 40 characters, and unique within your account: create one that already exists and you get the error above instead of a second environment that looks the same. Only the display name can be edited afterwards, inline from Rename.
Labels are permanent. The label is the machine identity that snapshots, database connections, log sources and pinned investigations all point at, so environments can be renamed but never deleted or re-spelled. Pick the name your team already says out loud.
Labelled database connections
In Settings → Database Connections, add one connection per environment. Each is stored as its own encrypted Key Vault secret, gets the same automatic read-only enforcement, and keeps its own provider and last-test status. They don't have to match: SQL Server for prod, PostgreSQL for staging. A tenant with one database uses the default label. The card itself is pictured under where to configure.
Catalog databases
If you keep a catalog or registry database that maps each of your tenants to its own database, you don't have to paste a fixed connection string. Set an environment's Kind to Catalog, give us the catalog's connection string, and write a small resolver script that looks the real connection string up:
const rows = connection.query({
table: 'tenants',
columns: ['server', 'database', 'username', 'password'],
where: [{ column: 'tenant_key', op: '=', value: resolveKey }],
limit: 1
});
if (rows.length === 0) throw new Error('unknown tenant');
const r = rows[0];
return 'Server=' + r.server + ';Database=' + r.database +
';User Id=' + r.username + ';Password=' + r.password + ';';The script sees exactly two globals. resolveKey is the lookup key you configure per environment (or the environment label if you leave it blank), and connection has a single query(...) method that runs a read-only, parameterised query against your catalog, in the same structured query format the agent uses rather than raw SQL. The script must return the connection string. The Test Connection button runs a real resolution end to end, including a live probe of the resolved connection.
Sandboxed by design
Resolver scripts run in an isolated, locked-down interpreter on a separate service that holds no credentials of its own: no network, no filesystem, no .NET access, and strict time (~2s), memory and statement budgets. The resolved connection string passes the same safety validation as one you paste in, and read-only access is enforced on both the catalog and the resolved database.
Labelled code snapshots
Tag an ingest with the environment it was built from using the X-Environment header (and optionally give the snapshot a human-readable name with X-Snapshot-Name):
curl -X POST "https://api.codepanion.app/api/ingest/$TENANT_ID" \
-H "Authorization: Bearer $CODEPANION_TOKEN" \
-H "Content-Type: application/gzip" \
-H "X-Commit-Sha: $COMMIT_SHA" \
-H "X-Environment: qa" \
-H "X-Snapshot-Name: QA build 2026-06-10" \
--data-binary @repo.tar.gzLabels are lowercase letters, digits and hyphens. Each environment keeps its own snapshot lineage: a qa upload chains to the previous qa snapshot. Uploads without a label keep working exactly as before.
Environments and codebases are separate axes: a codebase says which repository the code came from, an environment says which deployment it was built for. Labels apply within each codebase, so your billing-service codebase can carry its own qa and prod snapshots alongside another repo's.
Labelled log sources
Logs are labelled per environment too. In Settings → Log Sources, connect a log source (Seq directly, or Seq, Azure Monitor and CloudWatch Logs through the connector) under each environment label (qa, staging, prod) and the agent's search_logs and get_log_context tools read the environment they're pinned to. Log sources are configured in the app rather than pushed over the ingest endpoint; see the logs guide.
Asking about one environment
Pin an environment from the picker, or name it in your message ("why is checkout failing in QA?"), and the agent searches the QA snapshot, queries the QA database, and reads the QA logs together. When you don't pin or name one, it uses the default environment, and the audit log records which environment every query and log search ran against.
Good to know
This is how QA teams use Codepanion as more than a support tool: label a qa environment and investigate test failures with the agent before they ever reach production.