Tier 2: Remote Debugging

Tier 2: Remote Debugging

Tier 2 lets the agent investigate remote or production-like failures without asking you to SSH in and paste logs.

You Provide / Confirm

1. Create or select the target Host in the desktop app.
2. Choose the install path: generate a command to run on the target machine, or push the install over SSH.
3. Provide hints for the target service and logs, such as service name, port, log file, journalctl unit, or start command.
4. Approve the remote deployment and log source config generated by the agent.

Generated install commands encode host identity and bootstrap details such as --host-id, --transport direct|tunnel, --bind-address, --port, --bootstrap-token, and --require-auth. If you choose SSH push, the desktop app uses that Host’s SSH credentials to install and start superdev-agent.

Host ID Discipline

When writing remote host_ids, the agent must first call list_hosts. It may only use non-local hosts[].id values where is_self=false. Display names, SSH hostnames, IPs, and user-provided labels are not stable IDs.

The Agent Does

• Produces remote deployment / log source config from the Host plus service and log hints, previews it before writing, and waits for approval when required.
• Reads remote logs through the same tail_logs, search_logs, and get_log_context tools.
• Uses diagnose_service, analyze_trace_logs, and summarize_error_window to collect deterministic evidence.
• Writes a root-cause explanation with evidence, reasoning, confidence, and the next verification step.

Boundary

The remote debugging path is not “Agent tells the human to SSH and tail.” SuperDev exists so the agent and human see the same aggregated runtime evidence.

Next

• Evidence before cause
• Self-healing loop