Contents
Getting started
Using Codepanion
Connecting your tools
A connected log source closes the loop on an investigation. The agent already reads your code and queries your database; logs let it correlate a failing request with the exact log line, the stack trace, and the surrounding activity, without anyone hand-copying entries into the chat. Codepanion reads three log stores: Seq, Azure Monitor / Log Analytics and AWS CloudWatch Logs. Seq can be reached directly from our cloud; all three can be reached through the on-prem connector.
Connect a log source
Log sources are configured in the app, under Settings → Log Sources. You don't push logs to us over an ingest call. For a Seq server we reach directly, give us its base URL and an API key; we test the connection, then store the key as its own encrypted Key Vault secret. The key is never shown again and never returned by the API.
Two choices shape a source, and they are separate. The first is which store holds the logs: Seq, Azure Monitor / Log Analytics, or CloudWatch Logs. The second is Connection, how we reach it. Cloud (direct) means Codepanion calls the store itself, and today that is Seq only: its base URL has to be reachable from the internet. On-Prem Connector runs the query inside your network, and that is where all three stores are available, each behind the credential you pick for it (see on-prem logs). The agent's tools are the same whichever store answers.
If you'd rather drive it from a script, the same thing over the API:
POST /settings/log-sources/{environment}
{
"provider": "seq",
"baseUrl": "https://logs.acme.io",
"apiKey": "<your Seq API key>"
}You will rarely need the API directly. The Settings page above drives it, including a Test Connection button that live-probes the source before you save. Managing log sources is owner-only. An optional Seq signal id scopes every query to a saved Seq view. In the list, Edit loads a source back into the form below (re-enter the API key to change or re-test it, since we never hand it back) and Remove deletes it.
One source per environment
Each source is labelled with an environment (qa, staging, prod), exactly like your database connections and code snapshots. When an investigation is pinned to an environment, the log tools read that environment's source automatically, so the agent stays on one environment end to end: the QA build's code, the QA database, and the QA logs. A tenant with a single source can leave it under the default label and never think about it.
What the agent can do
Once a source is connected, two read-only tools appear in the agent's toolbelt. They're offered only when a log source is configured, so there are no dead buttons and no empty searches:
search_logsSearch the environment's logs by free text, minimum level, and time range ("everyerrormentioning order 88123 in the last hour"), newest first.get_log_contextPull the entries surrounding a moment in time, anchored on a log entry or a raw instant, widened by a window like5m, optionally narrowed to a single distributed trace. The "what else was happening then" view.
Both surface as plain-language tool steps in the investigation, and every call is recorded in the audit log against the environment it ran in. The agent never sees the API key: it's resolved from Key Vault per call.
Good to know
Connecting logs is what turns a "why is checkout failing in QA?" question into a complete answer: the failing code path, the offending row, and the log line that ties them together. It's how QA and engineering use the agent the same way support does.
On-prem logs (connector)
If your log store lives inside your network and must stay there, or if it is Azure Monitor or CloudWatch Logs, the on-prem connector reaches it for you. Set the source's Connection to On-Prem Connector and the agent routes search_logs and get_log_context over the connector's outbound channel, the same one it uses for the database. Codepanion holds no credential: the connector reaches your log store using a node-local key or the host's ambient cloud identity, on your side of the channel.
A connector-mode source asks how the connector should authenticate on its side. That choice picks the store the connector queries, and it decides what, if anything, we store:
- API Key (on the connector): Seq. The key and the server URL live on the connector's host as environment variables and never reach us.
- Azure Managed Identity: Azure Monitor / Log Analytics. The connector borrows its host's managed identity to query the workspace. You give us the workspace ID, which is not a secret, and no credential is stored at all.
- AWS IAM Role: CloudWatch Logs. The same arrangement on AWS: the connector's host IAM role reads the log group. You give us the log group and the region, both non-secret.
Connector-mode sources are marked as such in the list, next to the identity they use (Azure Managed Identity in the screenshot above), so Settings always tells you which environments we reach ourselves and which ones only your own network can. Those rows have no base URL to enter and no Test Connection button either, because the probe would have to run on your side of the channel.