What it does
Open a troubleshoot task and you get a chat that investigates. It reads your repository, and where you have connected an environment it can pull recent logs, run bounded read-only queries and execute commands you have explicitly allowed. Every step it takes is shown in the conversation.
It ends in a written diagnosis: root cause, the evidence behind it, impact, and a proposed fix. From there one click turns that diagnosis into a bugfix task that goes through the normal specify, approve, review pipeline.
Read-only is enforced, not requested
The agent cannot write, and that is a property of the system rather than an instruction in a prompt. It runs in plan mode with no editing tools, so it cannot change your checkout. Environment access goes through three narrow functions instead of a shell.
- SQL must be a single bounded SELECT. Statements are parsed and rejected before they run, the transaction is opened read-only, and a statement timeout and row cap apply. Point it at a role with SELECT-only grants and you have three independent layers.
- Commands match a literal allowlist you write, run without a shell, and an empty allowlist permits nothing at all.
- Log endpoints come from your configuration, never from the agent, so it cannot be steered into fetching something else.
Configured per environment
Each environment you connect has its own switches. Expose only logs on production while allowing SQL and a few commands on staging. A capability that is switched on but not fully configured is not granted, and the interface says so rather than pretending.