> For the complete documentation index, see [llms.txt](https://docs.warp.dev/llms.txt). > Markdown versions of each page are available by appending .md to any URL. # Cloud agent FAQs Answers about cloud agent execution, models, access, billing, workflows, and self-hosting, with links to setup and reference details. Cloud agents support factory workflows and standalone tasks. These short answers summarize common questions; the linked references own setup steps, compatibility details, and policy requirements. ## Architecture and execution ### Where do cloud agents run? What’s the architecture? Cloud runs execute on Warp-hosted compute or your infrastructure. Warp coordinates the run and tracks its results; execution location and inference routing are separate choices. See [Execution architecture](https://docs.warp.dev/platform/architecture/). ### What exactly are cloud agents in Warp? A cloud agent performs a task away from your laptop using instructions, tools, and runtime configuration. Run it as part of a factory workflow or start a standalone run without creating a factory. See [Cloud agents overview](https://docs.warp.dev/platform/). ### Can we intervene mid-run? Yes. Authorized users can inspect a run’s transcript and outputs and send instructions to steer work. Continuing a finished run or handing it off has separate requirements. See [Inspecting and steering runs](https://docs.warp.dev/platform/viewing-cloud-agent-runs/). ### Do cloud agents have access to Codebase Context and indexing? Indexing settings and the selected harness determine what indexed context is available. Check the requirements before relying on semantic repository search; agents can also inspect files with their runtime’s tools. See [Codebase Context for cloud runs](https://docs.warp.dev/agents/capabilities/codebase-context/). ### Can I access a shell inside a cloud agent environment? Are there limitations (Docker, Playwright, etc.)? Agents use the tools available in their execution environment. Add dependencies through the image or setup commands. Docker privileges, browser dependencies, and resource limits depend on the runtime, not just the prompt. See [Environment tools and dependencies](https://docs.warp.dev/factories/environments/configuring-environments/). ### Do cloud agents run as root inside the container? Linux container runs use a non-root user by default, but an image’s existing user and startup fallback can change the selected identity. Check user, home-directory, and sudo requirements for your image. See [Container users and permissions](https://docs.warp.dev/factories/environments/configuring-environments/#configure-container-users). ### Do cloud agents support a fully self-hosted, on-prem, or offline mode? Self-hosting moves execution to your infrastructure; it doesn’t make Warp’s coordination services offline. The worker and task runtime still need the required outbound network access. See [Self-hosting and required network access](https://docs.warp.dev/factories/self-hosting/security-and-networking/#network-requirements). ## Models ### Which models are supported? The available model selection depends on the harness and account. Use the current picker and model reference rather than assuming every harness exposes the same catalog. See [Model choice](https://docs.warp.dev/agents/inference/model-choice/). ### Can I choose which model cloud agents use? Yes. Select a model for the agent or run using the relevant interface or configuration. Keep model selection separate from environment setup and check the chosen harness’s available models. See [Selecting a model for a run](https://docs.warp.dev/factories/api-and-sdk/#agent-configuration). ### Can I authenticate cloud agents with my own ChatGPT or Claude Pro / Max plan? A [connected ChatGPT subscription](https://docs.warp.dev/agents/inference/chatgpt-subscription/#use-your-chatgpt-subscription) doesn’t fund cloud runs. Managed-secret setup uses funded Anthropic or Bedrock credentials for Claude Code and funded OpenAI API access for Codex, not local subscription sign-in. Worker-supplied self-hosted credentials follow a separate setup path. See [Harness authentication](https://docs.warp.dev/factories/harnesses/authentication/). ### Do you support local or private LLMs for compliance or air-gapped environments? Team-managed endpoints and cloud-provider BYOLLM offer customer-configured inference paths. Plan requirements and cloud support vary by option; private inference doesn’t make the entire platform air-gapped. See [Private inference options](https://docs.warp.dev/enterprise/enterprise-features/bring-your-own-llm/). ## Security and billing ### Will cloud storage for agent definitions, runs, and conversations be secure and encrypted? Run data is access-controlled and stored separately from the execution workspace. The security reference documents encryption; retention and provider agreements are separate questions and depend on the configured path. See [Security and encryption](https://docs.warp.dev/enterprise/security-and-compliance/security-overview/). ### Are cloud agents included in the Build plan, or is it a separate add-on? Access and funding depend on the plan and run identity. Runs use eligible included or purchased usage for applicable inference, hosted-compute, and platform charges; check the billed user’s or team’s requirements. See [Cloud access and usage billing](https://docs.warp.dev/platform/team-access-billing-and-identity/#usage-requirements). ### How do cloud agents handle API keys and secrets for agents? Grant only the credentials the task needs. Standalone managed secrets have team and personal scopes; factories have their own grants. Don’t put credentials in prompts or print them; redaction is a backstop. See [Standalone cloud secrets](https://docs.warp.dev/platform/secrets/). ## Workflows ### How do agents handle branching, merge conflicts, and multi-agent coordination with cloud agents? Choose branch ownership, file isolation, and integration responsibility before parallel editing. Agents sharing a host need separate worktrees or working copies; review the combined diff and resolve conflicts before merging. See [Branching and coordination](https://docs.warp.dev/platform/orchestration/#repository-isolation-and-review). ### Can cloud agents integrate with external tools, APIs, or services (like n8n connectors)? Yes, through configured MCP servers and tools available to the runtime. Install dependencies, provide permissions and credentials, and check network access separately; instructions alone don’t connect or authorize a service. See [Connecting external tools with MCP](https://docs.warp.dev/factories/mcp/). ### Can I export agent conversations and runs from cloud agents? Yes. Authorized callers can retrieve run details, normalized conversations, artifacts, and raw transcripts through the run interfaces. Use the documented retrieval paths rather than assuming every output is embedded in one response. See [Retrieving conversations and artifacts](https://docs.warp.dev/platform/orchestration/multi-agent-runs/#retrieving-conversations-and-artifacts). ### How do cloud agents handle environment access, files, and security compared to SSH-based setups? Sharing a conversation doesn’t grant repository, SSH, or service access. Configure repository identity, runtime credentials, and network permissions separately, and review which transcripts and outputs leave the execution workspace. See [Environment access and credential boundaries](https://docs.warp.dev/factories/self-hosting/security-and-networking/#data-boundaries). ### Can cloud agents review PRs like a teammate? Yes. Give the agent the changes and review criteria, such as correctness risks, missing tests, or maintainability. Configure the access needed to return comments or changes, and retain human merge review. See [PR review in GitHub Actions](https://docs.warp.dev/platform/integrations/github-actions/). ### Can cloud agents write unit tests? Yes. Provide the repository’s test command and dependencies, ask the agent to generate and run tests, and review coverage and assumptions. Passing generated tests doesn’t prove that the software has no defects. See [Test-generation instructions for recurring runs](https://docs.warp.dev/platform/triggers/scheduled-agents/#scheduling-a-skill). ### Can cloud agents do big refactors? Break the refactor into reviewable changes with validation checkpoints. Assign file ownership and isolated working copies, then integrate and test the combined result rather than treating parallel completion as proof of correctness. See [Splitting large refactors across agents](https://docs.warp.dev/platform/orchestration/#repository-isolation-and-review). ### Can cloud agents triage issues / tickets automatically? Yes. Define a triage skill, connect a supported trigger, and specify what context to gather and which labels or responses to propose. Trigger setup and write permissions differ between factory and standalone workflows. See [Building an issue-triage workflow](https://docs.warp.dev/guides/agent-workflows/build-a-triage-agent/). ### Can cloud agents do dependency upgrades? Yes. A scheduled skill can propose upgrades, run repository checks, and open a PR with a risk summary. Require review of conflicts, test results, and dependency changes instead of assuming unattended merging. See [Scheduled dependency maintenance](https://docs.warp.dev/platform/triggers/scheduled-agents/#scheduling-a-skill). ### Can cloud agents keep docs up to date? Yes. A scheduled skill can check for drift, run link and build validation, and propose documentation changes through a PR. Keep review and publishing requirements explicit. See [Scheduled documentation checks](https://docs.warp.dev/platform/triggers/scheduled-agents/#scheduling-a-skill). ## Self-hosting ### Where does my source code go with self-hosted agents? Repository checkouts and execution workspaces stay on your infrastructure. Code content can still appear in prompts, transcripts, and artifacts stored or transmitted as run data; review those boundaries separately. See [Source code, transcripts, and storage](https://docs.warp.dev/factories/self-hosting/security-and-networking/#data-boundaries). ### Can I use `oz agent run` in CI or existing runners? Yes. With unmanaged execution, your CI job or host invokes the CLI directly and provides its tools, checkout, and credentials. Warp tracks the session, while your system owns process lifecycle and isolation. See [Running agents in CI or existing hosts](https://docs.warp.dev/platform/unmanaged-execution/). ### Can self-hosted agents access services behind a VPN? Yes, when the task’s execution environment has the necessary access. A connected worker doesn’t establish that its container or Pod can reach the same VPN services, private repositories, or databases. See [VPN and private-service access](https://docs.warp.dev/factories/self-hosting/security-and-networking/#vpn-and-on-premises-access). ### Does self-hosting work with GitLab or other non-GitHub SCMs? Use the provider-specific integration or configure repository access in your execution environment. Factory connections and standalone host-based workflows have different setup paths; verify the credentials and network access for your SCM. See [Source-control integrations](https://docs.warp.dev/platform/integrations/). ### Do LLM requests still go through Warp with self-hosting? It depends on the harness and inference configuration. The Warp Agent routes requests through Warp; Claude Code and Codex call their providers directly. Self-hosted execution doesn’t, by itself, choose the inference route. See [Inference routing with self-hosting](https://docs.warp.dev/factories/self-hosting/security-and-networking/#llm-inference-and-byollm). ### What about large monorepos with long environment setup times? Unmanaged execution can reuse a pre-provisioned checkout and toolchain. Managed backends have separate mount, storage, and worktree options. Keep concurrent edits isolated rather than sharing one writable checkout. See [Pre-provisioned monorepos and managed storage](https://docs.warp.dev/platform/unmanaged-execution/#large-repositories). ### Do Kubernetes pods provide enough sandboxing for self-hosted agents? That depends on your cluster configuration and risk profile. Evaluate pod security, network policies, and RBAC; a Pod alone is not a guarantee that the isolation meets your organization’s requirements. See [Kubernetes security boundaries](https://docs.warp.dev/factories/self-hosting/security-and-networking/#kubernetes-backend). ## Image attachments ### Do cloud agents support image attachments? Yes. Interactive cloud conversations support image upload, clipboard paste, and drag-and-drop. Legacy CLI task-file attachments are a separate surface with their own limits. See [Interactive image attachments and CLI files](https://docs.warp.dev/agents/local-agents/agent-context/images-as-context/). ## Related pages - [Multi-agent orchestration](https://docs.warp.dev/platform/orchestration/) - [Orchestration patterns](https://docs.warp.dev/platform/orchestration/#common-patterns) - [Cloud agents overview](https://docs.warp.dev/platform/) - Choose a factory or standalone workflow - [Cloud agents quickstart](https://docs.warp.dev/platform/quickstart/) - Start a standalone run