Frequently Asked Questions

Network and VNet integration

Do I need VNet integration to use the agent?

No. The SRE Agent works fully without VNet integration. In Unrestricted mode (the default), the agent investigates incidents, runs tools, queries Azure resources, and takes management actions over the public internet. Control plane operations (resource discovery, ARM calls, Azure Monitor metrics) work regardless of network configuration.

VNet integration is for organizations that need:

• Egress control — restrict where data can flow
• Private endpoint access — reach Log Analytics, AKS, Key Vault, or databases behind private endpoints
• Network-level audit trails — see agent traffic in your NSG flow logs and firewall logs
• Compliance — meet enterprise policies that require all workload traffic to route through controlled network paths

What can the agent do without VNet?

Everything that doesn't require access to private-network-only resources:

• Investigate incidents using publicly accessible Azure resources
• Run Azure CLI and kubectl commands against public endpoints
• Query Log Analytics and Application Insights (if public access is enabled)
• Connect to GitHub, Jira, and other SaaS services
• Create and manage scheduled tasks and response plans
• Use all connectors and MCP servers

When should I enable VNet?

Enable VNet integration when:

• Your Log Analytics workspaces, AKS clusters, or databases have public access disabled (behind AMPLS or private endpoints)
• Your security policy requires all outbound traffic from production workloads to pass through a firewall
• You need to reach on-premises systems (via ExpressRoute or VPN) during investigations
• Compliance requires network-level visibility into where the agent sends data

For setup instructions, see Configure Network Controls. For architecture details, see Network Controls.

Can I switch network modes on a running agent?

Yes. You can switch between Unrestricted, Limited, and Azure VNet modes at any time. Settings persist across mode changes. Once a VNet is connected, the other mode cards are disabled until you disconnect the VNet.

Workspace disk capacity

How much disk does my agent's workspace have?

By default, 40 GiB. The workspace runs on a sandbox that enforces a fixed 1 CPU : 2 GiB memory : 20 GiB disk ratio, so a default workspace is provisioned with 2 CPU and 4 GiB of memory. Raising the disk raises the whole footprint.

My agent says "No space left on device". What does that mean?

The workspace volume is full. Because every subsystem writes to the same volume, a single exhaustion event produces several unrelated-looking symptoms at once:

Symptom	What is actually happening
No space left on device	The direct error.
Failed to create terminal task directory	Terminal commands cannot run — each one needs a scratch directory.
FileNotFoundError: No usable temporary directory found	Python's tempfile cannot write to any candidate directory. Not a Python or CLI problem.
npm error code ENOSPC, failed to launch connection, Connection closed	Connectors that bootstrap through npm cannot start. The agent then runs silently without those tools.
A connector or setting appears to be missing from the agent's configuration view	The configuration snapshot is itself written to disk, so it freezes at its last successful write. Treat it as stale until the disk is recovered.

Because the volume is shared, the reported symptom is often unrelated to whatever actually consumed the space.

What consumes workspace disk?

In rough order of impact:

• Connected code repositories. Clones are the most common cause. A repo that fails to clone on a full disk retries continuously, which keeps the volume pinned.
• Threads. Each thread keeps a persistent working area — generated artifacts, a directory per terminal command with its captured output, and spillover files for large tool results. This is reclaimed only when the thread is deleted.
• Connector package caches. A connector stuck in a launch-retry loop re-fetches its packages on every attempt, so it consumes space as well as failing.

How do I increase the workspace disk?

Enable the LargeDisk setting, which provisions 120 GiB (about 100 GiB usable — the remainder is headroom for the sandbox base image) with 6 CPU and 12 GiB of memory:

1. Open Settings and select the Experimental settings tab. (If your agent uses the classic navigation, go to Capabilities → Experimental settings instead.)
2. If LargeDisk is already listed, turn its toggle on (true). Otherwise, in the Add setting box at the bottom of the list, enter LargeDisk exactly (case-sensitive, no spaces) and select +. The new setting is added with its toggle on (true).
3. Select Save changes, then Restart and Save. Saving restarts the agent, which provisions a new sandbox with the larger disk.
4. After the agent is running again, run a terminal command (for example df -h /) in a new thread to confirm the larger volume. If the disk is still about 40 GiB, stop and start the agent.

The sandbox is only re-provisioned on restart, so the setting has no effect until the agent restarts.

Order matters

Enable LargeDisk before restarting. Restarting first just rebuilds the same content onto the same 40 GiB volume and the problem returns.

Is a larger disk enough on its own?

Often not. If an agent exhausts 40 GiB it will usually exhaust 120 GiB too, just more slowly — at that point the constraint is the rate of consumption, not capacity. Combine the larger disk with at least one of:

• Delete threads you no longer need. This is the only way to reclaim a thread's working area short of recreating the sandbox.
• Reduce what is cloned. Disconnect repositories you do not need, or enable sparse checkout to clone only the paths you use.
• Search code remotely. Where your source host supports it, use the connector's remote code-search tool instead of a local clone — it uses no workspace disk.
• Prefer summarized tool output over dumping large result sets into a thread.

Expect a periodic stop/start on long-lived, heavily used agents.

Is there an automatic cleanup or retention setting?

No. There is no age-based or size-based retention, no per-thread quota, and no scheduled cleanup for the workspace volume. Deleting threads and restarting the agent are the available mechanisms.

After recovering, do I need to re-run anything?

Yes. Any run that executed while the disk was full may have completed without terminal access and without connector-backed tools, without saying so. Re-run affected investigations and scheduled tasks and disregard their earlier conclusions.