Enterprise: Enterprise features, SSO, team management, and security. # Enterprise overview Canonical page: [/enterprise/](https://docs.warp.dev/enterprise/) > Warp Enterprise provides the security, control, and collaboration features organizations need to deploy Warp across their engineering teams at scale. Warp Enterprise is built for organizations that want to accelerate software development with agents while maintaining security, compliance, and administrative control. It brings Warp’s **Agentic Development Environment** to your entire engineering organization with the governance features IT and security teams require. Warp has two core products: * **Warp Terminal** - A modern terminal designed for agentic development where developers run commands, collaborate with agents, and orchestrate autonomous work from the command line. * **Oz** - Warp’s programmable agent for running and coordinating agents at scale. Oz powers all agents in Warp, whether they run locally or in the cloud, and provides the orchestration, tracking, and control plane for scalable agent workflows. ## Who Warp Enterprise is for [Section titled “Who Warp Enterprise is for”](#who-warp-enterprise-is-for) Warp Enterprise serves three primary audiences: * **IT admins and platform teams** - Deploy and manage Warp across your organization with SSO, centralized administration, and usage visibility * **Engineering managers** - Give your teams powerful agent development tools while enforcing coding standards and best practices through shared team resources * **Professional developers** - Accelerate your work across the entire SDLC with state-of-the-art agents, team knowledge sharing, and collaborative workflows that keep you in control ## Key capabilities [Section titled “Key capabilities”](#key-capabilities) ### Enterprise administration [Section titled “Enterprise administration”](#enterprise-administration) * **Single Sign-On (SSO)** - Authenticate via your existing identity provider (Okta, Microsoft Entra ID, Google Workspace, and more) * **Centralized Admin Panel** - Manage team settings, user permissions, and feature controls from one location * **User roles and permissions** - Control access with Team Owner, Team Admin, and Member roles * **Usage visibility** - Monitor team adoption and agent usage across your organization ### Security and compliance [Section titled “Security and compliance”](#security-and-compliance) * **SOC 2 Type II certified** - Meets enterprise security and compliance requirements * **Zero Data Retention (ZDR)** - No customer data is retained, stored, or used for training by contracted LLM providers * **Open source client** - Warp’s client code is published under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL) at [`warpdotdev/warp`](https://github.com/warpdotdev/warp) for security review and audit * **Bring Your Own LLM (BYOLLM)** - Route inference through your own cloud infrastructure (AWS Bedrock) * **Flexible deployment** - Choose Warp-hosted or hybrid deployment models * **Telemetry controls** - Configure what data is collected at the team level ### Team collaboration [Section titled “Team collaboration”](#team-collaboration) * **Warp Drive team workspace** - Share Workflows, Notebooks, Prompts, Plans, Rules, and Environment Variables across your team * **Codebase Context** - Team-level code indexing helps agents understand your repositories and generate accurate, context-aware responses * **MCP integrations** - Connect to your team’s tools (Linear, Sentry, Figma, GitHub, and more) for context-aware agent responses * **Session sharing** - Collaborate on terminal sessions and conversations with shareable links ### Agent capabilities [Section titled “Agent capabilities”](#agent-capabilities) * **State-of-the-art agents** - Multi-model agents with full terminal access, code editing, and autonomous task execution * **Cloud agents** - Run agents in the cloud for unlimited parallelization, background automation, and long-running workflows. Perfect for PR reviews, scheduled tasks, and distributed work across multiple repositories * **Integrated control plane** - Launch, orchestrate, and manage local, cloud, and autonomous agents from a unified interface. Track all agent activity across your team from the Oz dashboard * **Agent Profiles** - Customize agent behavior, models, autonomy levels, and permissions * **Rules and guardrails** - Enforce coding standards, tech stack preferences, and security practices through team-wide or project-specific rules * **Multi-agent support** - Support for all major models and CLI coding agents (Oz, Claude Code, Codex, Copilot) ## What this section covers [Section titled “What this section covers”](#what-this-section-covers) This section organizes Enterprise documentation to help you deploy, secure, and scale Warp across your organization: * **Getting started** - Installation, SSO setup, and onboarding for admins and developers * **Security and compliance** - Security overview and SSO configuration * **Enterprise features** - Bring Your Own LLM (BYOLLM) * **Team management** - Admin panel, roles and permissions, and access controls ## Getting started [Section titled “Getting started”](#getting-started) **For IT admins**: Start with the [Admin Panel](/enterprise/team-management/admin-panel/) to manage team settings, configure agent policies, and enforce security controls. See [Roles and permissions](/enterprise/team-management/roles-and-permissions/) for user access details. **For developers**: Jump to [Getting started for developers](/enterprise/getting-started/getting-started-developers/) to download Warp, log in, and start using key features like Codebase Context and Warp Drive. Or try the [Enterprise quickstart](/enterprise/getting-started/quickstart/) for a 10-minute walkthrough. **For security teams**: Review our [Security page](https://www.warp.dev/legal/security) and [Privacy documentation](/support-and-community/privacy-and-security/privacy/) to understand how Warp handles data, encryption, and compliance. ## Why enterprises choose Warp [Section titled “Why enterprises choose Warp”](#why-enterprises-choose-warp) Organizations adopt Warp Enterprise to: * **Accelerate development velocity** - Agents automate tedious tasks across the SDLC, from environment setup to incident response, so developers focus on what matters * **Maintain security and control** - Deploy on your infrastructure, route inference through your cloud accounts, and keep developers in control with full visibility and guardrails * **Scale best practices** - Share team knowledge, coding standards, and operational runbooks through Warp Drive to compound productivity gains across teams * **Reduce context switching** - Keep developers in flow with a terminal-first environment that integrates agents, code editing, and tool integrations in one place * **Get scaffolding built in** - Deploy agents at scale without building custom infrastructure—Warp provides orchestration, tracking, and collaboration out of the box ## Support and resources [Section titled “Support and resources”](#support-and-resources) * **Documentation** - Comprehensive guides throughout this enterprise section * **Contact sales** - [Schedule a demo or start a trial](https://www.warp.dev/contact-sales) * **Support** - Enterprise customers receive priority support via dedicated Slack/Teams channels * **Warp Guides** - Video tutorials and training at [docs.warp.dev/guides](/guides/) # Enterprise Analytics API Canonical page: [/enterprise/enterprise-features/analytics-api/](https://docs.warp.dev/enterprise/enterprise-features/analytics-api/) > Programmatically access team-level usage data for Warp's enterprise plans — per-team summaries, per-user rollups, and message-level activity events. The Enterprise Analytics API lets enterprise admins pull Warp usage data into their own dashboards, cost-allocation tooling, or audit pipelines. It exposes three read-only endpoints over HTTPS that return aggregated team metrics, per-user rollups, and message-level activity events for the agents your team runs in Warp and Oz. ## What you can do with the API [Section titled “What you can do with the API”](#what-you-can-do-with-the-api) * **Build productivity dashboards** - Track adoption across users and teams over time using `summary` and `users`. * **Allocate credit spend** - Break down usage by user, model, or run type (`local` vs. `cloud`) to attribute cost to teams or projects. * **Audit message-level activity** - Filter the `events` endpoint by `run_type`, `user_id`, `conversation_id`, `message_type`, or `tool_type` for compliance reviews and incident investigation. * **Power custom reporting** - Pipe the JSON responses into your own warehouse, BI tool, or alerting system. ## Prerequisites and access [Section titled “Prerequisites and access”](#prerequisites-and-access) Before you can call the API, your team must satisfy all of the following: * **Enterprise plan** - The Analytics API is available to all enterprise teams during Early Access; no separate enrollment is required. * **Admin role on the team** - Calls are rejected unless the authenticated user has admin-level permissions on the enterprise team. See [Roles and permissions](/enterprise/team-management/roles-and-permissions/). * **A personal Warp API key** - Authenticate requests with a key from **Settings** > **Cloud platform** > **Oz Cloud API Keys** in the Warp app. See [API Keys](/reference/cli/api-keys/) for step-by-step instructions. Agent API keys (including legacy team keys) are not accepted by these endpoints — only personal API keys belonging to a team admin work. * **Enterprise Usage Reporting toggle enabled** - In the Warp app, go to **Admin Panel** > **Privacy** and turn on **Enterprise Usage Reporting (Early Access)**. Until this toggle is on, no usage data is recorded for your team and the endpoints will return empty datasets even if every other prerequisite is met. Caution Personal API keys inherit the access of the user who created them. Treat them like any other admin credential and rotate them when team membership changes. ## Quickstart [Section titled “Quickstart”](#quickstart) The following example fetches a team-level summary for the last day. Set your API key first: ```bash export WARP_API_KEY="wk-..." ``` Then call the `summary` endpoint: ```bash curl "https://app.warp.dev/api/v1/enterprises/analytics/summary" \ -H "Authorization: Bearer $WARP_API_KEY" ``` Once an admin has turned on the **Enterprise Usage Reporting (Early Access)** toggle for your team, you’ll get a JSON payload aggregating credit usage and conversation counts across the team. Continue to the [Endpoints](#endpoints) section for per-endpoint details. ## Endpoints [Section titled “Endpoints”](#endpoints) All endpoints share the same base URL, authentication, and shared validation rules: * **Base URL** - `https://app.warp.dev/api/v1/enterprises/analytics` * **Authentication** - `Authorization: Bearer $WARP_API_KEY` header on every request. * **Dates** - Pass `start_date` and `end_date` as RFC 3339 timestamps with timezone (for example, `2026-04-01T00:00:00Z` or `2026-04-01T00:00:00-07:00`). When omitted, the API defaults to a 1-day window ending at the current time. `start_date` must be strictly before `end_date`; otherwise the request returns `400 Bad Request`. * **Performance** - Wider date ranges and finer `group_by_period` granularity scan more data and can take noticeably longer to return. For dashboards that refresh frequently, prefer narrower windows or coarser grouping. ### `GET /api/v1/enterprises/analytics/summary` [Section titled “GET /api/v1/enterprises/analytics/summary”](#get-apiv1enterprisesanalyticssummary) Returns a single team-level rollup of conversation counts, credit spend, and code-change activity for the requested window. When `group_by_period` is set, the response is a time series with one bucket per period. **Query parameters:** * `start_date` (optional) - RFC 3339 timestamp. Defaults to one day before `end_date`. * `end_date` (optional) - RFC 3339 timestamp. Defaults to the current time. * `group_by_period` (optional) - One of `day`, `week`, or `month`. When set, the resulting `period_list` is capped at 365 periods; longer ranges with finer granularity are rejected with `400 Bad Request`. **Example:** ```bash curl "https://app.warp.dev/api/v1/enterprises/analytics/summary?start_date=2026-04-01T00:00:00Z&end_date=2026-04-30T23:59:59Z&group_by_period=day" \ -H "Authorization: Bearer $WARP_API_KEY" ``` **Ungrouped response shape:** ```json { "data": { "local": { "total_conversations_count": 1234, "total_credits_spent": 8421.5, "code_changes": { "file_changes": { "suggested": 412, "accepted": 305 }, "lines_of_code": { "suggested": { "added_count": 9821, "removed_count": 2104 }, "accepted": { "added_count": 7102, "removed_count": 1488 } } } }, "cloud": { "total_conversations_count": 412, "total_credits_spent": 2310.4, "code_changes": { "file_changes": { "suggested": 88, "accepted": 64 }, "lines_of_code": { "suggested": { "added_count": 1450, "removed_count": 320 }, "accepted": { "added_count": 1102, "removed_count": 248 } } } } } } ``` **Grouped response shape (`group_by_period=day`):** ```json { "group_by_period": "day", "period_list": ["2026-04-01", "2026-04-02", "..."], "data": { "local": { "total_conversations_count": [42, 51, "..."], "total_credits_spent": [310.1, 412.5, "..."], "code_changes": { "file_changes": { "suggested": [12, 18, "..."], "accepted": [9, 14, "..."] }, "lines_of_code": { "suggested": { "added_count": [240, 380, "..."], "removed_count": [55, 90, "..."] }, "accepted": { "added_count": [180, 290, "..."], "removed_count": [40, 70, "..."] } } } }, "cloud": { "...": "same shape as local" } } } ``` In the grouped response, every leaf array is the same length as `period_list`, and the index of each value corresponds to the same index in `period_list`. Periods with no recorded activity are filled with default empty values (`0` for numeric counts and credit totals, and `0`-valued sub-objects for `code_changes`). ### `GET /api/v1/enterprises/analytics/users` [Section titled “GET /api/v1/enterprises/analytics/users”](#get-apiv1enterprisesanalyticsusers) Returns per-user aggregated usage, split into `local` (Warp app) and `cloud` (cloud agents) sections. Results are paginated. **Query parameters:** * `start_date` (optional) - RFC 3339 timestamp. Defaults to one day before `end_date`. * `end_date` (optional) - RFC 3339 timestamp. Defaults to the current time. * `group_by_period` (optional) - One of `day`, `week`, or `month`. When set, each user record’s per-run-type fields are arrays indexed by the response-level `period_list`. * `page` (optional) - Page number, 1-indexed. Default `1`. * `page_size` (optional) - Items per page. Default `10`. **Example:** ```bash curl "https://app.warp.dev/api/v1/enterprises/analytics/users?page=1&page_size=25" \ -H "Authorization: Bearer $WARP_API_KEY" ``` **Ungrouped response shape:** ```json { "data": [ { "user_id": "user-uuid-abc", "email": "alex@example.com", "local": { "distinct_conversation_count": 42, "credits_spent": 310.1, "model_usage": [ { "model_id": "claude-4-7-opus", "distinct_conversation_count": 30, "credits_spent": 240.0 } ], "code_changes": { "file_changes": { "suggested": 18, "accepted": 12 }, "lines_of_code": { "suggested": { "added_count": 412, "removed_count": 88 }, "accepted": { "added_count": 305, "removed_count": 64 } } } }, "cloud": { "...": "same shape as local" } } ], "pagination": { "current_page": 1, "page_size": 25, "total_pages": 4, "total_count": 87 } } ``` When `group_by_period` is set, each `local`/`cloud` block’s scalars become arrays indexed by the response-level `period_list` (same convention as the grouped `summary` response). Within `model_usage`, each entry’s `distinct_conversation_count` and `credits_spent` likewise become arrays. ### `GET /api/v1/enterprises/analytics/events` [Section titled “GET /api/v1/enterprises/analytics/events”](#get-apiv1enterprisesanalyticsevents) Returns paginated, message-level activity events for fine-grained audits and dashboards. Each row corresponds to a single message produced or processed by an agent — the same canonical message stream the client and Warp UI see. **Query parameters:** * `start_date` (optional) - RFC 3339 timestamp. Defaults to one day before `end_date`. The window between `start_date` and `end_date` cannot exceed 365 days. * `end_date` (optional) - RFC 3339 timestamp. Defaults to the current time. * `page` (optional) - Page number, 1-indexed. Default `1`. * `page_size` (optional) - Items per page. Default `10`. Maximum `100`. * `run_type` (optional) - Filter by `local` or `cloud`. * `user_id` (optional) - The unique identifier of a single team member, as returned by the `users` and `events` endpoints. * `conversation_id` (optional) - Restrict results to one conversation. * `message_type` (optional) - Filter by message variant. Common values include `agent_output`, `tool_call`, `tool_call_result`, `user_query`, and `agent_reasoning`; additional values are emitted as new agent capabilities ship. Internal scaffolding (for example `model_used`, `server_event`, `messages_received_from_agents`, `events_from_agents`, and `debug_output`) is not recorded and never appears here. * `tool_type` (optional) - For `tool_call` / `tool_call_result` messages, restrict to a specific tool. Values are the snake\_case name of the tool (for example `apply_file_diffs`, `run_shell_command`, `search_codebase`, `grep`, `call_mcp_tool`). Events are returned newest-first, ordered by `message_end_timestamp DESC, message_id DESC`. **Example:** ```bash curl "https://app.warp.dev/api/v1/enterprises/analytics/events?run_type=cloud&message_type=tool_call&tool_type=apply_file_diffs&page_size=100" \ -H "Authorization: Bearer $WARP_API_KEY" ``` **Response shape:** ```json { "data": [ { "message_id": "msg-uuid", "llm_request_ids": ["llm-req-uuid"], "message_type": "tool_call", "tool_type": "apply_file_diffs", "message_start_timestamp": "2026-04-15T19:21:08Z", "message_end_timestamp": "2026-04-15T19:21:11Z", "conversation_id": "conv-uuid", "user_id": "user-uuid-abc", "email": "alex@example.com", "user_selected_model": "auto", "run_type": "cloud", "model_ids": ["claude-4-7-opus"], "credit_charged": 0.42, "code_changes": { "file_changes": { "suggested": 3, "accepted": 2 }, "lines_of_code": { "suggested": { "added_count": 48, "removed_count": 12 }, "accepted": { "added_count": 36, "removed_count": 8 } }, "was_edited_by_user": false }, "git_context": { "head": "a1b2c3d", "branch": "feature/analytics-api" }, "error_type": null } ], "pagination": { "current_page": 1, "page_size": 100, "total_pages": 12, "total_count": 1180 } } ``` Fields are populated as follows: * `llm_request_ids` and `model_ids` are arrays. Most LLM-backed messages have a single entry, but some messages may be backed by multiple LLM requests. * `credit_charged` is the per-message proportional share of the backing LLM request’s cost. Messages with no LLM call (for example client-submitted `tool_call_result` rows) carry `0`. * `code_changes` is omitted (or `null`) for messages that don’t suggest or apply file changes. * `was_edited_by_user` is `true` when the user edited the diff before accepting, `false` when accepted as-is, and `null` when the message had no acceptance event. * `git_context` is omitted (or `null`) when no git state was captured for the message. * `error_type` is populated only when the backing LLM request errored. ## Pagination [Section titled “Pagination”](#pagination) The `users` and `events` endpoints use offset-based pagination with `page` and `page_size` query parameters. Every paginated response includes a `pagination` block: * `current_page` - The page returned, 1-indexed. * `page_size` - The number of items requested per page. * `total_pages` - The total number of pages available for the current query. * `total_count` - The total number of records matching the query across all pages. To iterate, request `page=1` first, then increment `page` until you’ve fetched `total_pages` pages. The `events` endpoint caps `page_size` at `100`; values above that are rejected. The `users` endpoint defaults to `page_size=10`. ## Common use cases [Section titled “Common use cases”](#common-use-cases) * **Executive dashboards** - Combine the `summary` endpoint’s grouped output with your BI tool to chart team-wide adoption and credit spend over time. * **Cost allocation** - Use the `users` endpoint to attribute credit spend to individuals, teams, or projects for chargeback or showback. * **Adoption monitoring** - Track per-user `distinct_conversation_count` over time to identify power users, onboard slow adopters, and measure rollout impact. * **Compliance audit trails** - Pull the `events` endpoint with `message_type=tool_call` filters to log code-changing actions for security review. ## FAQ [Section titled “FAQ”](#faq) ### How fresh is the data? [Section titled “How fresh is the data?”](#how-fresh-is-the-data) Usage data is recorded as agents run and is typically available within a few minutes. There is no guaranteed SLA on freshness during Early Access. ### Who can call the API? [Section titled “Who can call the API?”](#who-can-call-the-api) Any authenticated user with admin-level permissions on an enterprise team. Calls from non-admin users return `403 Forbidden`. ### What kind of API key works? [Section titled “What kind of API key works?”](#what-kind-of-api-key-works) Only **personal** Warp API keys created by an admin from **Settings** > **Cloud platform** > **Oz Cloud API Keys**. Agent API keys (including legacy team keys) are explicitly rejected by these endpoints. See [API Keys](/reference/cli/api-keys/) for how to create one. ### Are these calls billed? [Section titled “Are these calls billed?”](#are-these-calls-billed) No. Analytics API calls don’t consume Warp credits. ### What time range can I query? [Section titled “What time range can I query?”](#what-time-range-can-i-query) The `events` endpoint enforces a hard 365-day window between `start_date` and `end_date`. The `summary` and `users` endpoints don’t enforce a fixed window, but the grouped variants are capped at 365 periods. ## Related resources [Section titled “Related resources”](#related-resources) * [API Keys](/reference/cli/api-keys/) - Create and manage personal Warp API keys. * [Admin Panel](/enterprise/team-management/admin-panel/) - Manage team settings, including the **Privacy** section. * [Roles and permissions](/enterprise/team-management/roles-and-permissions/) - Required admin role for Analytics API access. * [Architecture and deployment](/enterprise/enterprise-features/architecture-and-deployment/) - Where enterprise data is stored and how it transits Warp’s infrastructure. # Architecture and deployment Canonical page: [/enterprise/enterprise-features/architecture-and-deployment/](https://docs.warp.dev/enterprise/enterprise-features/architecture-and-deployment/) > Understand Warp's system architecture and choose the right deployment model for your organization - Warp-hosted, self-hosted, or hybrid. Warp’s architecture separates the **control plane** (orchestration, observability, and LLM inference) from the **execution plane** (where agents run, code is accessed, and commands execute). This separation gives enterprise teams flexibility to choose where sensitive workloads run while maintaining centralized management and visibility. Use this information to evaluate which deployment model fits your organization’s security, compliance, and operational requirements. ## System architecture overview [Section titled “System architecture overview”](#system-architecture-overview) Warp’s cloud agent infrastructure has four key components: 1. **Trigger** - What starts an agent run (CI step, webhook, cron schedule, Slack mention, CLI command, or API/SDK call). 2. **Orchestration** - What decides what to run and tracks it (Oz orchestrator or your own system). 3. **Execution** - Where the agent actually runs (Warp-hosted environment, your infrastructure, or your existing CI/orchestrator). 4. **Visibility** - How the team monitors and intervenes (Oz dashboard, session sharing, APIs/SDKs). ### High-level data flow [Section titled “High-level data flow”](#high-level-data-flow) * **Warp terminal (client)** ↔ **Warp backend (control plane)** ↔ **LLM providers** * The Warp backend handles task orchestration, observability, and LLM inference routing. * LLM providers operate under **Zero Data Retention (ZDR)** agreements. They do not store or train on your data. * The **execution plane** is where source code is accessed, commands run, and build artifacts are produced. This can run on Warp’s infrastructure or yours. ## Warp-hosted (SaaS) [Section titled “Warp-hosted (SaaS)”](#warp-hosted-saas) Warp-hosted is the default deployment model. Agents run on Warp-managed infrastructure with no setup required from your team. ### How it works [Section titled “How it works”](#how-it-works) * Agents execute in **isolated Docker containers** on Warp-hosted infrastructure (GCP). * The Oz orchestrator manages agent lifecycle - provisioning, execution, monitoring, and cleanup. * Environments are ephemeral and destroyed after each run. ### Triggers [Section titled “Triggers”](#triggers) Warp-hosted agents can be triggered by: * **First-party integrations** - Slack, Linear, and other connected tools * **Scheduled agents** - Cron-like automation for recurring work * **CLI** - `oz agent run-cloud` for on-demand cloud execution * **API/SDK** - Programmatic triggers from your own systems ### When to use [Section titled “When to use”](#when-to-use) * You want the simplest path to scalable cloud agent execution. * You need to run many tasks in parallel without building sandboxing infrastructure. * Your security requirements are met by Warp’s SOC 2 Type II certified infrastructure with ZDR. ## Self-hosted execution [Section titled “Self-hosted execution”](#self-hosted-execution) For organizations that need agent execution and source code to remain within their own network boundary, Warp supports self-hosted execution. ### Split architecture [Section titled “Split architecture”](#split-architecture) Self-hosted deployments use a split architecture: * **Execution plane (customer-hosted)** - Source code repositories, build artifacts, shell commands, and runtime secrets stay on your infrastructure. Note that during agent interactions, code context is included in LLM prompts and session transcripts that route through Warp’s servers under ZDR agreements (see [What transits Warp’s servers](#what-transits-warps-servers)). * **Control plane (Warp-hosted)** - Task orchestration, observability data, and LLM inference route through Warp’s servers under Zero Data Retention (ZDR) agreements. ### Deployment modes [Section titled “Deployment modes”](#deployment-modes) **Unmanaged** - Use `oz agent run` to run agents in your existing orchestrator or CI environment. Supports Linux, macOS, and Windows with no Docker dependency. * Best for teams that already have CI/CD infrastructure or internal orchestrators. * You control scheduling, scaling, and environment setup. * Warp provides cloud connectivity, shared context, visibility, and session sharing. **Managed** - Run the `oz-agent-worker` daemon to let the Oz platform orchestrate agents in isolated Docker containers on your infrastructure. * The worker process connects to Oz via WebSocket and receives tasks automatically. * Agents run in isolated Docker containers managed by the worker. * You get the same orchestration capabilities as Warp-hosted, but execution stays on your infrastructure. ### Network requirements [Section titled “Network requirements”](#network-requirements) Self-hosted agents require **outbound-only** network access. No inbound network access is required. **Egress requirements:** * Outbound access to Warp’s backend services (for orchestration and observability) * For managed mode: access to Docker Hub and GitHub (for container images and repository access) ### When to use [Section titled “When to use”](#when-to-use-1) * Compliance or security requirements prevent using Warp-hosted compute. * Source code and execution must stay within your network boundary. * You want Oz orchestration and visibility without sending code to Warp’s infrastructure. ## Hybrid deployments [Section titled “Hybrid deployments”](#hybrid-deployments) Organizations can combine Warp-hosted and self-hosted execution to balance convenience with security requirements. ### How it works [Section titled “How it works”](#how-it-works-1) * Route sensitive workloads (e.g., production code, regulated data) to self-hosted agents. * Route less sensitive workloads (e.g., open-source tooling, internal utilities) to Warp-hosted agents. * Both execution modes share the same Oz dashboard, session sharing, and API/SDK visibility. ### Example configurations [Section titled “Example configurations”](#example-configurations) * **By sensitivity** - Production repositories run on self-hosted agents; staging and development run on Warp-hosted. * **By team** - Security-sensitive teams (e.g., infrastructure, payments) use self-hosted; other teams use Warp-hosted. * **By task type** - Scheduled maintenance tasks run on Warp-hosted; ad-hoc debugging runs self-hosted in dev environments. ## Data flow and boundaries [Section titled “Data flow and boundaries”](#data-flow-and-boundaries) Understanding what data stays where is critical for security and compliance decisions. ### What stays on customer infrastructure (self-hosted) [Section titled “What stays on customer infrastructure (self-hosted)”](#what-stays-on-customer-infrastructure-self-hosted) * **Source code** - Repository contents and version history * **Build artifacts** - Compiled outputs and generated files * **Shell commands** - Terminal commands and their output * **Runtime secrets** - Environment variables and credentials * **Execution logs** - Agent run logs and diagnostics ### What transits Warp’s servers [Section titled “What transits Warp’s servers”](#what-transits-warps-servers) * **Task orchestration** - Scheduling, routing, and lifecycle management * **Observability data** - Run status, duration, and metadata * **LLM inference** - Prompts and responses (which include code context from agent interactions) routed through Warp to contracted LLM providers under ZDR agreements * **Session sharing data** - Session transcripts, which include code context from agent interactions, when session sharing is enabled for monitoring and collaboration ## Choosing a deployment model [Section titled “Choosing a deployment model”](#choosing-a-deployment-model) Consider the following when selecting a deployment model: **Warp-hosted** is right if: * You want zero infrastructure management for agent execution. * Your security team is comfortable with SOC 2 Type II certified, ZDR-covered infrastructure. * You need maximum parallelization and scalability. **Self-hosted** is right if: * Compliance requirements mandate that code stays within your network. * You need to integrate with existing CI/CD or infrastructure tooling. * You want full control over the execution environment. **Hybrid** is right if: * Different teams or repositories have different security requirements. * You want the convenience of Warp-hosted for most work but need self-hosted for sensitive workloads. ## Related resources [Section titled “Related resources”](#related-resources) * [Deployment Patterns](/agent-platform/cloud-agents/deployment-patterns/) - Detailed patterns for CLI-only, Oz-hosted, and self-hosted setups * [Security overview](/enterprise/security-and-compliance/security-overview/) - Data handling, encryption, and compliance details * [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) - Route inference through your own cloud infrastructure * [Admin Panel](/enterprise/team-management/admin-panel/) - Configure agent policies and security settings * [Contact sales](https://www.warp.dev/contact-sales) - Discuss deployment options for your organization # Bring Your Own LLM Canonical page: [/enterprise/enterprise-features/bring-your-own-llm/](https://docs.warp.dev/enterprise/enterprise-features/bring-your-own-llm/) > Route Warp's agents through your AWS Bedrock models for billing control and infrastructure flexibility. Warp supports **Bring Your Own LLM (BYOLLM)** for enterprise teams that need to run inference on their own cloud infrastructure. With BYOLLM, your team can use Warp’s agents while routing inference through models hosted in your AWS Bedrock environment. This gives you control over cloud spend and model hosting, without changing how your team works in Warp. Caution BYOLLM currently supports **AWS Bedrock** only. Coming soon: Azure Foundry and Google Vertex support. ## Key features [Section titled “Key features”](#key-features) * **Cloud-native credentials** - No long-lived API keys. Interactive terminal sessions use each user’s AWS CLI session credentials; cloud agent runs assume an IAM role in your AWS account via OIDC. * **Admin-controlled IAM** - Admins define which IAM role(s) Warp can assume and which models are available via AWS Bedrock, with the ability to disable non-Bedrock model access entirely. * **Admin-enforced routing** - Team admins configure which models are available to users in AWS Bedrock, with the ability to disable non-Bedrock model access entirely. * **Consolidated billing** - Inference costs are billed directly to your AWS account, leveraging existing cloud commitments. ## How BYOLLM works [Section titled “How BYOLLM works”](#how-byollm-works) When BYOLLM is enabled, Warp redirects inference calls to your AWS Bedrock environment instead of using model providers’ direct APIs. Here’s the high-level flow: **Interactive terminal flow** 1. **Admin configures routing** - Your team admin sets routing policies in Warp’s admin settings (e.g., “Route Claude Opus 4.7 through AWS Bedrock; disable direct Anthropic API”). 2. **Team members authenticate** - Each team member authenticates to AWS locally using the AWS CLI (`aws login`). 3. **Warp routes requests** - When a team member uses an interactive agent in the terminal, Warp uses their short-lived session credentials to authenticate requests to your configured AWS Bedrock API endpoint. 4. **Inference executes in your cloud** - The model runs in your AWS account. Responses return to the Warp client. **Cloud agent flow** 1. **Admin configures routing** - Your team admin configures BYOLLM in the Admin Panel and provides an IAM role ARN that Warp can assume. See [Enabling BYOLLM for Cloud Agents](#enabling-byollm-for-cloud-agents) for setup details. 2. **Warp assumes the role** - At run start, Warp mints an OIDC token and assumes the configured IAM role in your AWS account to obtain temporary credentials. 3. **Warp routes requests** - The cloud agent uses those temporary credentials to call your configured AWS Bedrock endpoint. 4. **Inference executes in your cloud** - The model runs in your AWS account. Responses return to the cloud agent worker. ### Credential lifecycle [Section titled “Credential lifecycle”](#credential-lifecycle) BYOLLM uses **cloud-native IAM authentication**, not long-lived API keys: * **Automatic refresh** - Session tokens refresh automatically every \~15 minutes. Users can enable auto-refresh by opening **Settings** and searching for `AWS Bedrock`, or when prompted during first credential expiration. With auto-refresh enabled, sessions can run uninterrupted for up to 12 hours (depending on your AWS admin configuration). * **Per-user credentials** - Credentials are not shared across the organization. Your cloud provider’s default credential provider chain (e.g., AWS CLI) provisions and refreshes them locally. * **No storage or logging** - Warp never stores or logs your cloud session tokens on its servers. This approach ensures access management stays with your cloud provider, giving admins member-by-member control. ### Model availability [Section titled “Model availability”](#model-availability) BYOLLM supports the intersection of models that Warp supports and models available on AWS Bedrock. Currently, only **Claude models** (Anthropic) are available through AWS Bedrock. OpenAI and Google models are not available on Bedrock. To determine which models you can use with BYOLLM: * [Model Choice](/agent-platform/inference/model-choice/) - Full list of Warp-supported models. * [Supported models in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html) - AWS Bedrock model availability. A model must appear on both lists to be available through BYOLLM. ## Enabling BYOLLM [Section titled “Enabling BYOLLM”](#enabling-byollm) ### Prerequisites [Section titled “Prerequisites”](#prerequisites) Before configuring BYOLLM, confirm the following: * Your organization has the desired models enabled in AWS Bedrock. * You have admin access to both Warp’s [Admin Panel](/enterprise/team-management/admin-panel/) and your AWS IAM settings. * Team members have the AWS CLI installed locally. ### Step 1: Configure routing policies (admin) [Section titled “Step 1: Configure routing policies (admin)”](#step-1-configure-routing-policies-admin) In the [Admin Panel](/enterprise/team-management/admin-panel/), configure which models should route through AWS Bedrock: 1. From the [Admin Panel](/enterprise/team-management/admin-panel/), navigate to the **Models** page. 2. Select which models should use your cloud provider (e.g., “Claude Opus 4.7 via AWS Bedrock”). 3. Optionally, disable direct API access to enforce provider-only routing. ### Step 2: Provision IAM roles (cloud admin) [Section titled “Step 2: Provision IAM roles (cloud admin)”](#step-2-provision-iam-roles-cloud-admin) Grant your team members the necessary permissions in AWS. Use least-privilege IAM policies. **Example: AWS Bedrock minimum IAM policy** ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "BedrockModelAccess", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/*", "arn:aws:bedrock:*:*:inference-profile/*", "arn:aws:bedrock:*:*:application-inference-profile/*" ] } ] } ``` ### Step 3: Authenticate locally (team member) [Section titled “Step 3: Authenticate locally (team member)”](#step-3-authenticate-locally-team-member) Each team member authenticates to AWS using the AWS CLI: ```bash aws login ``` Confirm your AWS environment and region are correctly configured before using Warp. ### Step 4: Validate [Section titled “Step 4: Validate”](#step-4-validate) Run a test prompt in Warp using a model configured for BYOLLM routing. Verify: * The request completes successfully. * Logs appear in AWS CloudWatch. ## Enabling BYOLLM for cloud agents [Section titled “Enabling BYOLLM for cloud agents”](#enabling-byollm-for-cloud-agents) Cloud agents authenticate to AWS Bedrock differently from the local terminal flow above. Instead of relying on each user’s AWS CLI session, Warp assumes an IAM role you provision in your AWS account using OIDC identity federation. ### Prerequisites [Section titled “Prerequisites”](#prerequisites-1) Before configuring BYOLLM for cloud agents, confirm the following: * You have admin access to both Warp’s [Admin Panel](/enterprise/team-management/admin-panel/) and your AWS IAM settings. ### Step 1: Set up Warp as an OIDC identity provider in AWS (cloud admin) [Section titled “Step 1: Set up Warp as an OIDC identity provider in AWS (cloud admin)”](#step-1-set-up-warp-as-an-oidc-identity-provider-in-aws-cloud-admin) Before AWS can trust tokens issued by Warp, register Warp as an OpenID Connect (OIDC) identity provider in IAM. This is a one-time setup per AWS account. 1. Open the [Identity providers](https://console.aws.amazon.com/iam/home#/identity_providers) page in the AWS IAM console. 2. Click **Add provider**. 3. For **Provider type**, choose **OpenID Connect**. 4. For **Provider URL**, enter `https://app.warp.dev`. 5. For **Audience**, enter `sts.amazonaws.com`. 6. Click **Add provider**. After the provider is created, copy its ARN — it will look like `arn:aws:iam:::oidc-provider/app.warp.dev`. You’ll reference this ARN in the trust policy in the next step. For more detail, see AWS’s [Create an OpenID Connect (OIDC) identity provider in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html) guide. ### Step 2: Provision an assumable IAM role (cloud admin) [Section titled “Step 2: Provision an assumable IAM role (cloud admin)”](#step-2-provision-an-assumable-iam-role-cloud-admin) Create an IAM role that Warp can assume via OIDC, then attach the minimum Bedrock permissions policy. Use least-privilege IAM policies. The role setup has two parts: 1. A **trust policy** that allows Warp’s OIDC identity to call `sts:AssumeRoleWithWebIdentity`. 2. A **permissions policy** that grants the minimum Bedrock inference permissions. #### Trust policy requirements [Section titled “Trust policy requirements”](#trust-policy-requirements) This trust policy authorizes any cloud-hosted run from your team. The `sub` claim Warp signs has the shape `scoped_principal:/:`, where `` is `user` for user-triggered runs or `service_account` for [cloud agent](/agent-platform/cloud-agents/agents/) runs. The `/*` pattern below covers both. **Example trust policy** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/app.warp.dev" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "app.warp.dev:sub": "scoped_principal:/*" }, "StringEquals": { "app.warp.dev:aud": "sts.amazonaws.com" } } } ] } ``` Replace the account ID, issuer host, and team UID with values for your environment. The `` is the Warp team UID for the team that will be allowed to assume this role. You can find it in your team’s [Admin Panel](/enterprise/team-management/admin-panel/) URL as the path segment after `/admin/`. For example, in `https://app.warp.dev/admin/HzjUdNkg8Uiq8gp6FMgfxe/models`, the team UID is `HzjUdNkg8Uiq8gp6FMgfxe`. #### Permissions policy [Section titled “Permissions policy”](#permissions-policy) Attach the minimum Bedrock invoke permissions policy to the role: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "BedrockModelAccess", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/*", "arn:aws:bedrock:*:*:inference-profile/*", "arn:aws:bedrock:*:*:application-inference-profile/*" ] } ] } ``` After you create the role, copy its ARN. You’ll paste it into the **Models** page in the next step. ### Step 3: Configure routing policies (admin) [Section titled “Step 3: Configure routing policies (admin)”](#step-3-configure-routing-policies-admin) Attach the IAM role from Step 2 to your team or to a specific named agent. #### Option A: Team-wide [Section titled “Option A: Team-wide”](#option-a-team-wide) This applies the OIDC role to all cloud agent runs on the team. 1. In the [Admin Panel](/enterprise/team-management/admin-panel/), navigate to the **Models** page. 2. Under the **AWS Bedrock** host configuration, paste the IAM role ARN from Step 2 into the **Role ARN** field. 3. Select which models should route through AWS Bedrock. #### Option B: Per named agent [Section titled “Option B: Per named agent”](#option-b-per-named-agent) This applies the OIDC role only to runs from a specific named agent. In the Oz web app: 1. [Create a new agent](/agent-platform/cloud-agents/oz-web-app/#creating-a-new-agent) or edit an existing one. 2. In the agent form, expand the **AWS Bedrock** section. 3. Choose **Custom** and paste the IAM role ARN from Step 2. 4. Ensure the agent’s default model is one that’s enabled for Bedrock under the Admin Panel **Models** page. New runs for this agent will authenticate to Bedrock using the configured role. ### Step 4: Validate the configuration [Section titled “Step 4: Validate the configuration”](#step-4-validate-the-configuration) Start a test cloud agent run using a model configured for BYOLLM routing. Verify: * The request completes successfully. * Logs appear in AWS CloudWatch. ## BYOLLM usage and billing behavior [Section titled “BYOLLM usage and billing behavior”](#byollm-usage-and-billing-behavior) ### Billing [Section titled “Billing”](#billing) When a request routes through BYOLLM: * **Warp does not consume AI credits** for that request. * Cloud agent runs still consume platform and compute credits for orchestration and the cloud agent’s compute. See [The three credit buckets](/support-and-community/plans-and-billing/platform-credits/#the-three-credit-buckets) for more on credit types. ### Routing behavior [Section titled “Routing behavior”](#routing-behavior) Warp’s agents automatically select the best model for your task while respecting your admin’s routing policies. If you configure a model for BYOLLM, requests for that model route to AWS Bedrock. ### Failover behavior [Section titled “Failover behavior”](#failover-behavior) If a BYOLLM request fails (e.g., due to role assumption errors, insufficient permissions, or provider quota limits), Warp attempts to fall back to the next available model your admin has enabled. For example, if Claude Opus 4.7 on Bedrock fails but your admin also enabled it via direct API, Warp falls back to the direct API to avoid disruption. If a fallback uses a direct API model, that request consumes Warp credits. If no fallback is available (e.g., the admin disabled all non-Bedrock models), Warp displays a clear error message. ## Security and data handling [Section titled “Security and data handling”](#security-and-data-handling) ### Credential security [Section titled “Credential security”](#credential-security) * **No long-lived API keys** — BYOLLM uses cloud-native IAM with short-lived session tokens. * **Per-user authentication** — Each team member authenticates individually; credentials are not shared. * **No storage or logging** — Warp never stores or logs your cloud session tokens on its servers. ### Zero Data Retention (ZDR) [Section titled “Zero Data Retention (ZDR)”](#zero-data-retention-zdr) Warp maintains **SOC 2 compliance** and has **Zero Data Retention (ZDR)** agreements with its contracted LLM providers. However, when using BYOLLM: * **Your** cloud account settings determine data retention policies. * Warp cannot enforce ZDR for requests routed through your infrastructure. * If your cloud account does not have ZDR enabled, your provider may retain data according to their terms. ### Auditability [Section titled “Auditability”](#auditability) * Warp keeps all runs fully steerable and logged within Warp. * Your cloud account retains provider-side logs (usage, latency, errors). ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) ### Common errors [Section titled “Common errors”](#common-errors) * **Missing or expired local credentials** (interactive terminal use) — Re-authenticate using `aws login`. To avoid interruptions, enable auto-refresh by opening **Settings** and searching for `AWS Bedrock`, or when prompted during credential expiration. * **Role assumption failed** (cloud agent runs) — Verify the IAM trust policy, issuer host, team UID restriction, and the configured role ARN in Warp. * **Missing OIDC provider** (cloud agent runs) — Confirm the OIDC provider exists in your AWS account for the issuer host referenced in the trust policy. * **Insufficient permissions** — Verify your IAM policy includes the required Bedrock actions and any needed resources. * **Region or model mismatch** — Confirm the model is enabled in your AWS region and that your environment is configured for the correct region. * **Provider quota limits** — Check your AWS Bedrock quota and request increases if needed. ### Debugging steps [Section titled “Debugging steps”](#debugging-steps) 1. Confirm the configured role ARN is the one you intended Warp to assume. 2. Check the IAM trust policy and verify the issuer host, `sub`, and `aud` conditions match your Warp configuration. 3. Check the attached IAM policy for the required Bedrock permissions. 4. Confirm the model ID and region match your Warp configuration. 5. Inspect AWS CloudWatch logs for request details and errors. ## FAQ [Section titled “FAQ”](#faq) ### How is BYOLLM different from BYOK? [Section titled “How is BYOLLM different from BYOK?”](#how-is-byollm-different-from-byok) **BYOK (Bring Your Own API Key)** lets individual users add their own API keys for direct model provider access (e.g., Anthropic, OpenAI, Google). Warp stores keys locally on the user’s device. **BYOLLM (Bring Your Own LLM)** routes inference through your organization’s cloud infrastructure (AWS Bedrock) using cloud-native IAM. Admins configure it at the admin level and it applies to the entire team. | Feature | BYOK | BYOLLM | | ------------------- | ----------------------- | --------------------------------- | | Configuration level | User | Admin/Team | | Authentication | API keys (local) | IAM role assumed by Warp via OIDC | | Billing | Direct to provider | Your cloud account | | Data locality | Provider infrastructure | Your cloud infrastructure | ### Does BYOLLM work with Auto? [Section titled “Does BYOLLM work with Auto?”](#does-byollm-work-with-auto) Auto model selection is disabled if an admin disables **any** Direct API model, regardless of AWS Bedrock configuration. When Direct API models remain enabled and BYOLLM is configured, Auto picks the best model for the task. If the selected model is also enabled for AWS Bedrock, the request routes through Bedrock; otherwise it routes through the Direct API. ### Where does compute run and who pays? [Section titled “Where does compute run and who pays?”](#where-does-compute-run-and-who-pays) Inference runs in **your AWS account**, which AWS bills directly. Warp does not consume AI credits for BYOLLM-routed inference. Cloud agent runs continue to consume platform and compute credits for orchestration. See [The three credit buckets](/support-and-community/plans-and-billing/platform-credits/#the-three-credit-buckets) for more. ### What data does Warp store? Do you store our cloud credentials? [Section titled “What data does Warp store? Do you store our cloud credentials?”](#what-data-does-warp-store-do-you-store-our-cloud-credentials) Warp **does not store or log** your cloud credentials. * **Interactive terminal use** — Credentials are used transiently to sign requests and are never persisted on Warp servers. * **Cloud agent runs** — Temporary AWS credentials are used only for the duration of the run and are not retained after it ends. ### Can admins enforce provider-only routing and disable Warp-managed models? [Section titled “Can admins enforce provider-only routing and disable Warp-managed models?”](#can-admins-enforce-provider-only-routing-and-disable-warp-managed-models) Yes. Admins can configure routing policies to require specific models to use BYOLLM and disable direct API access to Warp-managed model endpoints. ## Related resources [Section titled “Related resources”](#related-resources) * [Bring Your Own API Key](/agent-platform/inference/bring-your-own-api-key/) * [Model Choice](/agent-platform/inference/model-choice/) — Full list of supported models * [Admin Panel](/enterprise/team-management/admin-panel/) — Configure team settings * [Contact Sales](https://www.warp.dev/contact-sales) — Get help with enterprise setup # Enterprise FAQ Canonical page: [/enterprise/getting-started/faq/](https://docs.warp.dev/enterprise/getting-started/faq/) > Answers to common questions about Warp Enterprise, including login issues, SSO, and getting started. ## Login and SSO [Section titled “Login and SSO”](#login-and-sso) ### I can’t log in with SSO [Section titled “I can’t log in with SSO”](#i-cant-log-in-with-sso) **Problem:** Error message when trying to log in via SSO. **Solution:** 1. Make sure you’re logging in through the [Warp login page](https://app.warp.dev/login), not your SSO provider’s portal. 2. Select **Continue with SSO** and enter your work email or domain. 3. If you have an existing Warp account, log in with your original credentials and [link your Warp account to SSO first](https://app.warp.dev/link_sso). 4. Complete the linking process. 5. Log out and log back in with **Continue with SSO**. ### I logged in with another method before and can’t use SSO now [Section titled “I logged in with another method before and can’t use SSO now”](#i-logged-in-with-another-method-before-and-cant-use-sso-now) **Problem:** You created a Warp account with email/Google/GitHub, but your organization now requires SSO. **Solution:** 1. Go to the [Warp login page](https://app.warp.dev/login). 2. Log in with your original method. 3. Navigate to the [SSO linking page](https://app.warp.dev/link_sso). 4. Complete the linking process. 5. Log out and log back in with **Continue with SSO**. ### Warp won’t open from my SSO provider [Section titled “Warp won’t open from my SSO provider”](#warp-wont-open-from-my-sso-provider) **Problem:** Clicking Warp in Okta/Microsoft Entra ID portal shows an error. **Solution:** This is a known limitation. Warp cannot be launched directly from SSO provider portals. Instead: 1. Go to the [Warp login page](https://app.warp.dev/login). 2. Click **Continue with SSO**. 3. Complete authentication. ## Team and access [Section titled “Team and access”](#team-and-access) ### Team invite links not working [Section titled “Team invite links not working”](#team-invite-links-not-working) **Common causes:** * Invite link expired or was revoked. * User’s email domain doesn’t match configured restrictions. **Solution:** 1. Generate a new invite link. 2. Verify domain restrictions match the user’s email. ### Users can’t see new admin settings [Section titled “Users can’t see new admin settings”](#users-cant-see-new-admin-settings) **Problem:** You changed a setting in the Admin Panel, but users don’t see the change. **Solution:** 1. Verify the setting is not set to “Respect User Setting.” 2. Ask users to restart Warp to force a settings refresh. 3. Confirm users are members of the correct team. 4. Check that users have logged in with SSO (not a personal account). ## Additional help [Section titled “Additional help”](#additional-help) For more troubleshooting, see: * [Troubleshooting login documentation](/support-and-community/troubleshooting-and-support/troubleshooting-login-issues/) * Contact your team admin for organization-specific issues. * Reach out to Warp support via your team’s dedicated Slack/Teams channel. * Join Warp’s [Slack community](https://go.warp.dev/join-preview) to connect with other Warp users and engineers. # Getting started for developers Canonical page: [/enterprise/getting-started/getting-started-developers/](https://docs.warp.dev/enterprise/getting-started/getting-started-developers/) > Download Warp, log in to your team, and start using agents, Codebase Context, and collaborative features to accelerate your development workflow. This guide helps developers get up and running with their team in Warp. You’ll learn how to download Warp, log in with your organization’s SSO, and configure key features like Codebase Context, Warp Drive, and Agent Profiles to accelerate your work across the entire SDLC (all while staying in your terminal). When you use agents in Warp, you’re working with **Warp’s built-in agents**. Oz is Warp’s programmable agent for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. Oz provides the orchestration, tracking, and control plane that makes scaling agent workflows seamless. ## Step 1: Download and install Warp [Section titled “Step 1: Download and install Warp”](#step-1-download-and-install-warp) Warp is available for macOS, Linux, and Windows. ### Download Warp [Section titled “Download Warp”](#download-warp) Visit the [Warp download page](https://www.warp.dev/download) and select your platform: * **macOS** - Download the `.dmg` installer (macOS 10.15 Catalina or later) * **Linux** - Download the `.deb`, `.rpm`, or use the install script * **Windows** - Download the `.exe` installer (Windows 10 or later) ### Install Warp [Section titled “Install Warp”](#install-warp) **macOS:** 1. Open the downloaded `.dmg` file. 2. Drag Warp to your Applications folder. 3. Launch Warp from Applications or Spotlight. **Linux:** ```bash # Debian/Ubuntu sudo dpkg -i warp-terminal_*.deb # Fedora/RHEL sudo rpm -i warp-terminal-*.rpm # Or use the install script curl -fsSL https://www.warp.dev/install.sh | bash ``` **Windows:** 1. Run the downloaded `.exe` installer. 2. Follow the installation wizard. 3. Launch Warp from the Start menu. ## Step 2: Log in to your team [Section titled “Step 2: Log in to your team”](#step-2-log-in-to-your-team) ### Logging in with SSO [Section titled “Logging in with SSO”](#logging-in-with-sso) If your organization uses SSO (most enterprise teams do): 1. Launch Warp. 2. When prompted, log in or create an account. 3. Click **Continue with SSO**. 4. Enter your work email or your organization’s domain. 5. Complete authentication with your SSO credentials when redirected to your identity provider. Caution Do not attempt to launch Warp directly from your SSO provider’s app portal (e.g., Okta dashboard). This will result in an error. Always log in through the [Warp login page](https://app.warp.dev/login). ### Logging in with an invite link [Section titled “Logging in with an invite link”](#logging-in-with-an-invite-link) If you received an invite link from your team admin: 1. Click the invite link in your email or message. 2. From the signup page, log in using SSO if it’s configured for your team, otherwise use one of the other sign in methods (Google, GitHub, or email). 3. After authentication, you’ll automatically join your team. ### Linking an existing account to SSO [Section titled “Linking an existing account to SSO”](#linking-an-existing-account-to-sso) If you were using Warp before your organization enabled SSO: 1. Go to the [Warp login page](https://app.warp.dev/login). 2. Log in with your original method (email, Google, or GitHub). 3. Once logged in, navigate to the [SSO linking page](https://app.warp.dev/link_sso). 4. Follow the prompts to link your account to SSO. 5. From now on, use **Continue with SSO** to log in. ## Step 3: Set up key features [Section titled “Step 3: Set up key features”](#step-3-set-up-key-features) ### Codebase Context [Section titled “Codebase Context”](#codebase-context) Codebase Context indexes your Git repositories so agents can understand your code and provide accurate, context-aware responses across large, multi-repo systems. **Setting up Codebase Context:** First, enable codebase indexing in your settings: 1. Go to **Settings** > **Code** > **Indexing and projects**. 2. Toggle **Enable Codebase Indexing** to turn it on. 3. Optionally, enable **Index new folders by default** to automatically index repositories as you navigate to them. Caution Codebase Context is a feature your team admin controls. If you don’t see these settings or they are disabled, contact your admin to enable this feature for your team. **Indexing your repositories:** Once codebase indexing is enabled, you can index individual repositories: 1. Navigate to a Git repository in your terminal. 2. Run the `/init` command. 3. Warp begins indexing your codebase. 4. You’ll be prompted to create an `AGENTS.md` file (optional but recommended). **What gets indexed:** * All Git-tracked files in your repository * Up to 200,000 files per repository * Files excluded in `.gitignore` or `.warpindexingignore` are automatically skipped **Privacy:** During indexing, your code is sent to Warp’s servers for processing where embeddings are created and stored. The code itself is not saved—only the embeddings are persisted. This allows agents to understand your codebase structure and context without storing your actual source code. ### Agent Profiles [Section titled “Agent Profiles”](#agent-profiles) Agent Profiles let you configure how Warp’s built-in agents behave. Profiles give you direct control over model selection, autonomy, tools, and permissions for your agent workflows. **Creating an Agent Profile:** 1. Go to **Settings** > **Agents** > **Profiles**. 2. Click **New Profile**. 3. Configure: * **Name and description** * **Model** - Choose which LLM to use * **Autonomy level** - How much agents can do without asking * **Tools** - Enable/disable terminal use, code editing, web search * **Permissions** - What agents can access (repos, files, secrets) 4. Click **Save**. **Using profiles:** Switch between profiles based on your task: * **High autonomy** for routine tasks like writing tests or updating docs * **Low autonomy** for sensitive operations like infrastructure changes * **Specific models** for cost optimization or task requirements ### Warp Drive [Section titled “Warp Drive”](#warp-drive) Warp Drive is your workspace for saving and sharing Workflows, Notebooks, Prompts, Rules, and Environment Variables. **Accessing Warp Drive:** 1. Click the tools panel icon in the top left of Warp. 2. Click the Warp Drive icon from the top of the tools panel. 3. Two Warp Drive sections display: * **Team** (top) - Resources shared across your team. * **Personal** (bottom) - Your individual resources. **What you can add to Warp Drive:** * **Workflows** - Parameterized commands you use repeatedly (e.g., deploy scripts, environment setup) * **Notebooks** - Interactive runbooks combining markdown and executable code blocks * **Prompts** - Saved agent prompts for recurring tasks (e.g., “review this PR”, “write unit tests”) * **Plans** - Agent-generated execution plans for complex tasks that agents can then run step-by-step * **Rules** - Coding standards and conventions agents should follow * **Environment Variables** - Configuration that can be loaded into your terminal session **Creating your first Workflow:** 1. From Warp Drive, click **+** in your Personal or Team section. 2. Select **Workflow**. 3. Enter a name, description, and command. 4. Add parameters if needed (e.g., `{{branch_name}}`). 5. Click **Save**. **Using team resources:** Your team admin may have already created shared resources. Explore the Team section of Warp Drive to see what’s available—including onboarding notebooks, deployment workflows, and coding standards rules. ### MCP (Model Context Protocol) [Section titled “MCP (Model Context Protocol)”](#mcp-model-context-protocol) MCP connects Warp’s agents to external tools and services for enhanced context. **Configuring MCP servers:** 1. Go to **Settings** > **Agents** > **MCP servers** or access via Warp Drive. 2. Browse the library of available MCP servers: * **Linear** - Access issues and project context * **Sentry** - Pull error tracking and stack trace information * **Figma** - Reference designs and specifications * **GitHub** - Access repository and PR context * And more… 3. Click **+** next to a server to add it. 4. Configure credentials and connection details. 5. Toggle the server on/off as needed. Your team may have shared MCP configurations. Check for a share icon next to team-configured servers to use them without manual setup. ## Step 4: Start using Warp [Section titled “Step 4: Start using Warp”](#step-4-start-using-warp) ### Everyday workflows [Section titled “Everyday workflows”](#everyday-workflows) Warp keeps you in your terminal with agent help across the entire SDLC: **Environment setup** * “Set up Node 20, Python 3.12, and Docker Desktop” * Save setup steps as a Workflow in Warp Drive for future use **Understanding codebases** * “How does authentication flow through this system?” * “What patterns does this repo use for error handling?” **Writing code** * Use the `/plan` command for complex features * Review diffs in real-time with the code review panel * Leave comments on specific lines for the agent to address **Debugging** * Start a debugger (`gdb`, `lldb`) and bring in an agent * Agents can operate debuggers and REPLs in natural language * Attach terminal output to agent conversations for analysis **Version control** * “Stage these changes and write a detailed commit message” * “Create a PR with a description following our template” * Set up Rules to enforce Git commit conventions **Testing** * “Write unit tests for this function following our existing patterns” * “Run the test suite and explain what failed” * Configure cloud agents to run test suites and validate coverage on PRs in the background ### Learning resources [Section titled “Learning resources”](#learning-resources) * **Warp Guides** - Short video tutorials in [Warp Guides](/guides/) * Getting Started with Warp * Warp Code features * Developer workflows * MCP, Rules, and Prompts * **Documentation** - Comprehensive guides in the [Warp docs](https://docs.warp.dev) ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) For common login, SSO, and access issues, see the [Enterprise FAQ](/enterprise/getting-started/faq/). ## Next steps [Section titled “Next steps”](#next-steps) Now that you’re set up: * **Explore agent capabilities** - Learn about [agents in Warp](/agent-platform/local-agents/overview/) and [cloud agents](/agent-platform/cloud-agents/overview/) * **Contribute to team knowledge** - Add useful Workflows, Prompts, and Rules to your team’s Warp Drive to compound productivity gains across your team * **Stay updated** - Check the [Warp changelog](/changelog/) for new features ## Support and feedback [Section titled “Support and feedback”](#support-and-feedback) * **Send feedback** - Use `Cmd+Shift+F` (macOS) or `Ctrl+Shift+F` (Linux/Windows) or go to **Help** > **Send Feedback** * **Request features** - Share ideas by [sending us feedback](/support-and-community/troubleshooting-and-support/sending-us-feedback/) * **Get help** - Enterprise teams have access to priority support via dedicated Slack/Teams channels * **Join the community** - Connect with other Warp users in our [Slack community](https://go.warp.dev/join-preview) # Getting started with Warp Enterprise Canonical page: [/enterprise/getting-started/getting-started-enterprise/](https://docs.warp.dev/enterprise/getting-started/getting-started-enterprise/) > Set up Warp Enterprise for your organization with SSO configuration, team management, and admin controls. This guide walks your IT or platform admin through initial Warp setup for your organization: configuring SSO, creating your team, inviting users, and setting Admin Panel policies. ## Prerequisites [Section titled “Prerequisites”](#prerequisites) Before you begin: * You have an active Warp Enterprise subscription * You have admin access to your organization’s identity provider (Okta, Microsoft Entra ID, Google Workspace, etc.) * You’ve identified which team members should have admin privileges in Warp ## Step 1: Configure Single Sign-On (SSO) [Section titled “Step 1: Configure Single Sign-On (SSO)”](#step-1-configure-single-sign-on-sso) Warp uses SSO to authenticate users and control access to your organization’s Warp team. Warp supports Okta, Microsoft Entra ID, Google Workspace, OneLogin, and any SAML 2.0 or OIDC compatible provider through [WorkOS](https://workos.com). SSO setup is coordinated with Warp’s team — contact your account team or [enterprise support](https://www.warp.dev/contact-sales) to get started. For the full setup process and supported providers, see [Single Sign-On (SSO)](/enterprise/security-and-compliance/sso/). **Before rolling out to your team**, test SSO login in an incognito window to confirm it works. See [Testing SSO](/enterprise/security-and-compliance/sso/#testing-sso) for steps. ## Step 2: Create and configure your team [Section titled “Step 2: Create and configure your team”](#step-2-create-and-configure-your-team) ### Creating your team [Section titled “Creating your team”](#creating-your-team) During Enterprise onboarding, Warp’s team will work with you to set up your team. This typically happens in one of two ways: * **Warp provisions your team** - In most cases, Warp creates the team on your behalf and adds your admin so you can begin configuration right away. * **You create or bring your own team** - If you already have a Warp team, or prefer to create one yourself, Warp’s team will apply the Enterprise plan to it during onboarding. In either case, the Enterprise plan must be applied by Warp internally — this cannot be self-served. Your account team will coordinate this with you. To get started, contact your account manager. ### Team settings [Section titled “Team settings”](#team-settings) Some team settings are configured in different places: * **Team name** - Configured in **Settings** > **Teams** in the Warp app. Help users identify the right team to join. * **Domain restrictions** - Limit team invites to specific email domains (e.g., `@yourcompany.com`) * **Auto-join** - Automatically adds users to your team when they sign in via SSO from your configured domain. The domain must be configured by the Warp team during onboarding — contact your account team to set up or update your team domain. * **SSO** - Configured through WorkOS, not the Admin Panel. See [Step 1](#step-1-configure-single-sign-on-sso). ## Step 3: Invite and manage users [Section titled “Step 3: Invite and manage users”](#step-3-invite-and-manage-users) ### Inviting users [Section titled “Inviting users”](#inviting-users) There are several ways to add users to your Warp team: **Option 1: Invite by email** 1. Navigate to **Settings** > **Teams**. 2. Enter email addresses in the **Invite by Email** field (comma-separated). 3. Click **Invite**. **Option 2: Share invite link** 1. Navigate to **Settings** > **Teams**. 2. Copy the team invite link. 3. Share the link via email, Slack, or your preferred communication channel. **Option 3: Domain auto-join** 1. Once your team domain is configured, users who sign in via SSO from your domain are automatically added to your Warp team. ### User roles and permissions [Section titled “User roles and permissions”](#user-roles-and-permissions) Warp has three user roles: * **Team Owner** - Has full access to the Admin Panel and can manage team settings, invite users, assign roles, and transfer ownership of the team. There can only be one Owner. * **Team Admin** - Same permissions as the Owner, except they can’t transfer ownership of the team. * **Member** - Standard access to Warp features and team resources ### Managing admins [Section titled “Managing admins”](#managing-admins) To promote or demote team admins: 1. Navigate to **Settings** > **Teams** > **Team Members**. 2. Find the user you want to modify. 3. Click the **…** (three dots) next to their name. 4. Select **Promote to admin** or **Demote admin**. ## Step 4: Configure the Admin Panel [Section titled “Step 4: Configure the Admin Panel”](#step-4-configure-the-admin-panel) The Admin Panel gives you centralized control over Warp features, permissions, and usage across your team. ### Accessing the Admin Panel [Section titled “Accessing the Admin Panel”](#accessing-the-admin-panel) 1. In Warp, open **Settings**. 2. Navigate to the **Billing and usage** section. 3. Click **Open Admin Panel**. Alternatively, visit the [Warp Admin Panel](https://app.warp.dev/admin) directly. ### Key Admin Panel sections [Section titled “Key Admin Panel sections”](#key-admin-panel-sections) * **Billing** - View your plan type and AI usage limit information * **Teams** - Manage team members, roles, and invites — the same controls available in **Settings** > **Teams** in the Warp app * **AI** - Configure general and AI autonomy settings for your team * **Models** - Configure which models are available to your team and AWS Bedrock * **Code** - Enable Codebase Context for your team * **Platform** - Configure cloud agent settings * **Privacy** - Configure user-generated content data collection, cloud conversation storage, and enterprise secret redaction * **Sharing** - Configure direct link sharing and “anyone with link” sharing permissions ### How settings enforcement works [Section titled “How settings enforcement works”](#how-settings-enforcement-works) Settings configured in the Admin Panel are enforced at the team level: * **Enforced settings** - Cannot be overridden by individual users (e.g., BYOLLM routing policies) * **Respect User Setting** - Defers to each user’s own preference, letting individual team members configure that setting themselves ## Step 5: Set up team resources [Section titled “Step 5: Set up team resources”](#step-5-set-up-team-resources) ### Enable Codebase Context [Section titled “Enable Codebase Context”](#enable-codebase-context) Codebase Context indexes your Git repositories to help agents understand your code across large, multi-repo systems: 1. Navigate to **Admin Panel** > **Code**. 2. Toggle **Codebase Indexing** to **Enabled**. Warp prompts team members to index repositories when they navigate to a Git-tracked directory. ### Create shared Warp Drive resources [Section titled “Create shared Warp Drive resources”](#create-shared-warp-drive-resources) Populate your team’s Warp Drive with shared resources to scale best practices and compound productivity gains: * **Workflows** - Parameterized commands for common tasks (deployments, environment setup) * **Notebooks** - Interactive runbooks for onboarding and operational procedures * **Prompts** - Saved agent prompts for recurring tasks (code review, test generation) * **Rules** - Coding standards and conventions that agents should follow * **Environment Variables** - Shared configuration for development environments See [Warp Drive documentation](/knowledge-and-collaboration/warp-drive/) for details on creating team resources. ### Configure MCP integrations [Section titled “Configure MCP integrations”](#configure-mcp-integrations) Connect Warp to your team’s tools for enhanced agent context. Navigate to **Settings** > **Agents** > **MCP servers** to get started. Some integrations (like Linear, GitHub, and Sentry) are available to enable with a single click, while you can also add any custom MCP server configuration your team needs. Once configured, click the share icon on a server to make it available to your team. See the [MCP documentation](/agent-platform/capabilities/mcp/) for full configuration details. ## Next steps [Section titled “Next steps”](#next-steps) Once your team is set up: * **For developers** - Share the [Getting started for developers](/enterprise/getting-started/getting-started-developers/) guide with your team * **Agent Profiles** - Configure default [Agent Profiles](/agent-platform/capabilities/agent-profiles-permissions/) for different types of work to give teams appropriate autonomy and control * **BYOLLM** - Set up [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) to route inference through your cloud infrastructure for data locality and cost control * **Monitor usage** - Review usage analytics in the Admin Panel to track adoption and measure engineering productivity gains * **Self-hosting** - Run agents on your own infrastructure to control where agents run and keep repository clones on your own machines. See [Self-hosting](/agent-platform/cloud-agents/self-hosting/) for setup instructions ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) ### SSO login issues [Section titled “SSO login issues”](#sso-login-issues) For common SSO problems (login failures, account linking, provider portal errors), see [SSO troubleshooting](/enterprise/security-and-compliance/sso/#troubleshooting). ### Team invite links not working [Section titled “Team invite links not working”](#team-invite-links-not-working) **Common causes:** * Invite link expired or was revoked * User’s email domain doesn’t match configured restrictions **Solution:** 1. Generate a new invite link. 2. Verify domain restrictions match user’s email. ## Support and resources [Section titled “Support and resources”](#support-and-resources) * [Admin Panel documentation](/enterprise/team-management/admin-panel/) * [Troubleshooting login issues](/support-and-community/troubleshooting-and-support/troubleshooting-login-issues/) * [Contact enterprise support](https://www.warp.dev/contact-sales) - Priority support via dedicated Slack/Teams channel # Enterprise quickstart Canonical page: [/enterprise/getting-started/quickstart/](https://docs.warp.dev/enterprise/getting-started/quickstart/) > Get up and running with Warp Enterprise in under 10 minutes. Log in, set up your terminal, and run your first agent. This quickstart walks you through the essentials: logging in via SSO, setting up Warp, and running your first agent. You can complete this in under 10 minutes. ## Step 1: Log in via SSO [Section titled “Step 1: Log in via SSO”](#step-1-log-in-via-sso) 1. Go to the [Warp login page](https://app.warp.dev/login). 2. Click **Continue with SSO**. 3. Enter your work email or your organization’s domain. 4. Complete authentication with your identity provider. Caution Do not launch Warp from your SSO provider’s app portal (e.g., Okta dashboard). Always log in through the [Warp login page](https://app.warp.dev/login). If you have an existing Warp account from before your organization enabled SSO, [link your Warp account to SSO first](https://app.warp.dev/link_sso). ## Step 2: Download and set up Warp [Section titled “Step 2: Download and set up Warp”](#step-2-download-and-set-up-warp) 1. Visit the [Warp download page](https://www.warp.dev/download) and select your platform (macOS, Linux, or Windows). 2. Install Warp: * **macOS** - Open the `.dmg` and drag Warp to Applications. * **Linux** - Install via `.deb`, `.rpm`, or the install script. * **Windows** - Run the `.exe` installer. 3. Launch Warp and log in with SSO (Step 1). 4. Verify you see your team name in **Settings** > **Teams**. ## Step 3: Configure and run your first agent [Section titled “Step 3: Configure and run your first agent”](#step-3-configure-and-run-your-first-agent) When you use agents in Warp, you’re working with **Warp’s built-in agents**. Oz is Warp’s programmable agent for running and coordinating agents at scale, whether they run locally on your machine or in the cloud. ### Index your codebase [Section titled “Index your codebase”](#index-your-codebase) 1. Navigate to a Git repository in Warp. 2. Warp automatically detects the repo and begins indexing. 3. Optionally, run `/init` to manually trigger indexing or re-indexing after significant code changes. 4. Once indexed, agents understand your code structure, patterns, and conventions. ### Run your first agent locally [Section titled “Run your first agent locally”](#run-your-first-agent-locally) Start a conversation right in the terminal. Try the following prompt: ```plaintext Explain the architecture of this project ``` Oz reads your codebase, understands its structure, and responds with a context-aware explanation. ### Try more prompts [Section titled “Try more prompts”](#try-more-prompts) * **Write code** - “Add input validation to the signup form” * **Debug** - “Why is this test failing?” (paste the error output) * **Explore** - “What patterns does this repo use for error handling?” * **Plan** - Use `/plan` to have Oz create a structured task plan for complex features ## Step 4: Run a cloud agent [Section titled “Step 4: Run a cloud agent”](#step-4-run-a-cloud-agent) Cloud agents run in the cloud for background work, unlimited parallelization, and long-running tasks. ### Create an environment [Section titled “Create an environment”](#create-an-environment) Environments define the execution context for cloud agents (repo access, dependencies, secrets, compute). You can create an environment in several ways: **Option 1: Slash command in Warp** From the Warp app terminal input, run the command: ```plaintext /create-environment ``` This launches an interactive flow that guides you through environment setup. **Option 2: Oz web app** Go to the [Environments page](https://app.warp.dev/environments) and click **Create Environment**. ### Run a cloud agent [Section titled “Run a cloud agent”](#run-a-cloud-agent) Once your environment is ready, use the following command to launch a cloud agent (use the environment ID from above): ```bash oz agent run-cloud --env my-env --prompt "Review the open PRs in this repo" ``` Monitor and steer cloud agents from the Oz dashboard or directly in Warp. ## Next steps [Section titled “Next steps”](#next-steps) * **Set up key features** - Follow the full [Getting started for developers](/enterprise/getting-started/getting-started-developers/) guide to configure Codebase Context, Warp Drive, MCP integrations, and Agent Profiles. * **Explore cloud agents** - Learn about [cloud agents](/agent-platform/cloud-agents/overview/) for background automation and parallel workflows. * **Explore guides** - Visit [Warp Guides](/guides/) for video tutorials and end-to-end workflows. # Security overview Canonical page: [/enterprise/security-and-compliance/security-overview/](https://docs.warp.dev/enterprise/security-and-compliance/security-overview/) > Understand Warp's security architecture, data handling practices, and compliance certifications to ensure your organization's requirements are met. Warp builds security and compliance into its core, keeping **developers in control** while enabling powerful agent workflows. This overview explains how Warp handles your data, what security controls are available, and how Warp meets enterprise security standards. ## Transparency and control [Section titled “Transparency and control”](#transparency-and-control) Warp’s security philosophy centers on **transparency and developer control**: * **Complete visibility** - View exactly what telemetry is collected through our [exhaustive telemetry table](/support-and-community/privacy-and-security/privacy/#exhaustive-telemetry-table) * **Real-time monitoring** - Use Warp’s [Network Log](/support-and-community/privacy-and-security/network-log/) to monitor all network requests in real time * **Opt-out controls** - Disable telemetry and crash reporting at any time while retaining full functionality * **Team-level enforcement** - Admins can configure telemetry and data collection policies for the entire organization * **Open source client** - Warp’s client code is published under [AGPL v3](https://github.com/warpdotdev/warp/blob/master/LICENSE-AGPL) at [`warpdotdev/warp`](https://github.com/warpdotdev/warp), so security teams can audit the codebase directly. See [Contributing to Warp](/support-and-community/community/contributing/) for the source repository and the security reporting process. ## What telemetry does Warp collect and why? [Section titled “What telemetry does Warp collect and why?”](#what-telemetry-does-warp-collect-and-why) ### Zero Data Retention (ZDR) [Section titled “Zero Data Retention (ZDR)”](#zero-data-retention-zdr) Warp has **Zero Data Retention (ZDR)** agreements with its contracted LLM providers (Anthropic, OpenAI, Google), meaning they do not store or train on your data. ZDR applies across all Warp plans. How data collection works by plan: * **Free tier** - Individual users can disable data collection in **Settings** > **Privacy**. * **Paid teams** - Team admins can enforce data collection settings for the entire team. Data collection is enabled by default. * **Business and Enterprise** - Team admins can enforce data collection settings for the entire team. Data collection is **disabled by default**. Enterprise subscriptions also include: * **Team-level enforcement** - Admins configure data collection and telemetry policies for the entire organization through the Admin Panel * **Secret redaction** - All AI interactions automatically apply [secret redaction](/support-and-community/privacy-and-security/secret-redaction/) to prevent sensitive data exposure ### Telemetry categories [Section titled “Telemetry categories”](#telemetry-categories) When telemetry is enabled, Warp collects: 1. **Product usage analytics** - High-level metrics on feature adoption and usage patterns (e.g., “Agent Mode was opened,” “workflow was executed”). 2. **Performance and stability** - Crash reports, error tracking, and performance metrics to identify and fix issues. When data collection is disabled, Warp does not collect: * Personally identifiable information beyond user IDs and email addresses * Network traffic or external API calls ### Disabling telemetry [Section titled “Disabling telemetry”](#disabling-telemetry) Users can opt out of telemetry individually: 1. Navigate to **Settings** > **Privacy**. 2. Toggle off **Help improve Warp** and/or **Send crash reports**. With telemetry disabled, Warp stops collecting usage and interaction data for analytics purposes. Team admins can enforce telemetry settings organization-wide through the Admin Panel. On Business and Enterprise plans, data collection is disabled by default. ## Data handling and privacy [Section titled “Data handling and privacy”](#data-handling-and-privacy) ### Where your data lives [Section titled “Where your data lives”](#where-your-data-lives) * **Code and files** - Stay on your machine unless you explicitly use features that transmit them (e.g., Codebase Context indexing, session sharing, Warp Drive team resources) * **Codebase Context** - During indexing, code is sent to Warp’s servers to generate embeddings; the raw code is not stored, only the resulting embeddings are retained * **Agent requests** - Warp sends requests to contracted LLM providers (Anthropic, OpenAI, Google) with Zero Data Retention agreements for Enterprise teams * **BYOLLM** - Requests are proxied through Warp’s servers to your cloud infrastructure, where inference runs. Warp does not store the content of these requests. * **Self-hosted cloud agent execution** - Repository clones, build artifacts, runtime secrets, and execution workspaces stay on your infrastructure. Orchestration metadata, session transcripts, and LLM inference requests and responses route through Warp under ZDR, and can include code context from agent interactions. ### Encryption [Section titled “Encryption”](#encryption) * **In transit** - All data transmitted to Warp servers uses TLS 1.2 or higher * **At rest** - Warp encrypts all user data at rest using AES-256 ### Secret redaction [Section titled “Secret redaction”](#secret-redaction) Warp automatically detects and redacts sensitive information before sending any data to LLM providers, keeping developers in control of what gets shared: * API keys and tokens * Passwords and secrets * SSH keys and certificates * Custom secret patterns (configurable via Admin Panel) See [Secret Redaction documentation](/support-and-community/privacy-and-security/secret-redaction/) for details. ### Data retention [Section titled “Data retention”](#data-retention) * **ZDR** - Warp’s contracted LLM providers do not retain or train on your data * **Telemetry data** - When collected, Warp retains telemetry data indefinitely for analytics and debugging * **User accounts** - Data deletion requests are processed securely within 30 days at no cost, following verified authentication and compliance with legal and contractual obligations ## Compliance and certifications [Section titled “Compliance and certifications”](#compliance-and-certifications) ### SOC 2 Type II [Section titled “SOC 2 Type II”](#soc-2-type-ii) Warp is SOC 2 Type II certified, demonstrating compliance with industry-standard security controls for: * **Security** - Infrastructure protection, access controls, and monitoring * **Availability** - System uptime and disaster recovery * **Confidentiality** - Data protection and privacy controls * **Processing integrity** - Accurate, complete, and authorized processing SOC 2 reports are available to Enterprise customers upon request. ## Infrastructure security [Section titled “Infrastructure security”](#infrastructure-security) ### Warp-hosted infrastructure [Section titled “Warp-hosted infrastructure”](#warp-hosted-infrastructure) When using Warp’s hosted infrastructure: * **Cloud provider** - Hosted on GCP with SOC 2 and ISO 27001 certified datacenters * **Network isolation** - Workloads run in isolated VPCs with strict network policies Warp’s operational security practices — including access controls, monitoring, and vulnerability management — are validated through SOC 2 Type II certification. See [Compliance and certifications](#compliance-and-certifications) for details. ### Self-hosted deployments [Section titled “Self-hosted deployments”](#self-hosted-deployments) Enterprise teams can self-host cloud agent execution to control where agents run and keep repositories on their own infrastructure. Self-hosted deployments use a split architecture: * **Execution plane (customer-hosted)** - Repository clones, build artifacts, runtime secrets, and container filesystem state stay on your infrastructure * **Control plane (Warp-hosted)** - Session transcripts (which include code context from agent interactions), orchestration metadata, and LLM inference route through Warp’s servers under Zero Data Retention (ZDR) agreements. Warp does not persistently store your source code or use it for model training Two deployment modes are available: * **Unmanaged** - Use `oz agent run` to run agents in your existing orchestrator or CI environment. Supports Linux, macOS, and Windows with no Docker dependency. * **Managed** - Run the `oz-agent-worker` daemon to let the Oz platform orchestrate agents in isolated Docker containers on your infrastructure. Agent runs are fully tracked and steerable in both modes. No inbound network access is required. **Network egress requirements** Self-hosted agents require outbound access to Warp’s backend services and, for the managed architecture, Docker Hub and GitHub. ## Access controls and authentication [Section titled “Access controls and authentication”](#access-controls-and-authentication) ### Single Sign-On (SSO) [Section titled “Single Sign-On (SSO)”](#single-sign-on-sso) Warp supports SSO via Okta, Microsoft Entra ID, Google Workspace, OneLogin, and any SAML 2.0 or OpenID Connect (OIDC) compatible provider. Admins can require SSO for all team members and enforce MFA through your identity provider. See [Single Sign-On (SSO)](/enterprise/security-and-compliance/sso/) for setup instructions, SCIM provisioning, account linking, and troubleshooting. ### Team permissions [Section titled “Team permissions”](#team-permissions) Warp uses role-based access control with three roles — Team Owner, Team Admin, and Member — to manage team access and Admin Panel privileges. See [User roles and permissions](/enterprise/getting-started/getting-started-enterprise/#user-roles-and-permissions) for details. Resource sharing in Warp Drive has granular controls for who can view, edit, and share. ### Admin Panel governance [Section titled “Admin Panel governance”](#admin-panel-governance) The Admin Panel gives security and IT teams centralized control over AI behavior, data handling, and sharing policies. Settings can be **enforced** (overriding individual user preferences organization-wide) or set to **respect user setting** (deferring to individual preferences). Security-relevant controls include: * **Privacy** - Configure user-generated content (UGC) data collection, cloud conversation storage, and enterprise secret redaction * **Sharing** - Restrict or permit direct link sharing and “anyone with link” sharing permissions * **AI** - Configure AI autonomy settings and general agent behavior for the team * **Models** - Control which LLM models are available to team members, including AWS Bedrock * **Platform** - Configure cloud agent access and settings ## Security features for developers [Section titled “Security features for developers”](#security-features-for-developers) ### Bring Your Own LLM (BYOLLM) [Section titled “Bring Your Own LLM (BYOLLM)”](#bring-your-own-llm-byollm) Route agent inference through your own cloud infrastructure for complete control: * **Data locality** - Interactive agent inference runs in your AWS account * **Cloud-native IAM** - Authenticate using your user’s existing identity and access management process * **No key storage** - Warp never stores your cloud credentials or API keys * **Billing control** - Inference costs billed directly to your cloud account See [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) for configuration details. ### Docker Sandboxes [Section titled “Docker Sandboxes”](#docker-sandboxes) Isolate agent execution in containerized environments: * **Process isolation** - Agents run in separate Docker containers, isolated from your host system * **Resource limits** - Configure CPU, memory, and disk quotas per sandbox * **Network controls** - Restrict outbound network access from sandboxes * **Ephemeral environments** - Sandboxes are destroyed after use, leaving no trace ### Agent permissions [Section titled “Agent permissions”](#agent-permissions) Configure what agents can access and execute: * **Tool restrictions** - Enable/disable terminal use, code editing, web search, and file system access * **Repository scoping** - Limit agents to specific repositories or directories * **Execution approvals** - Require manual approval for sensitive commands * **Visibility** - When cloud conversation storage is enabled, agent actions are logged with full context for review ## Incident response and support [Section titled “Incident response and support”](#incident-response-and-support) ### Security issue reporting [Section titled “Security issue reporting”](#security-issue-reporting) If you discover a security vulnerability in Warp: 1. Email . 2. Include detailed steps to reproduce. 3. Do not publicly disclose until Warp has addressed the issue. Warp follows responsible disclosure practices and works with reporters to coordinate disclosure timelines. ### Enterprise support [Section titled “Enterprise support”](#enterprise-support) Enterprise customers receive priority security support: * **Dedicated channels** - Private Slack/Teams channels for security questions * **Security advisories** - Proactive notifications of security updates * **Incident assistance** - Support during security incidents or breach investigations * **Compliance assistance** - Help with compliance questionnaires and audits ## Additional resources [Section titled “Additional resources”](#additional-resources) * [Warp privacy policy](https://www.warp.dev/legal/privacy-policy) * [Warp Trust Center](https://trust.warp.dev) — security documentation and compliance reports. See also [Trust Center](/enterprise/security-and-compliance/trust-center/) for details on requesting SOC 2 reports, subprocessors, and vendor security assessments. * [Warp subprocessors list](https://www.warp.dev/legal/subprocessors) * **Privacy documentation** - [Privacy guide](/support-and-community/privacy-and-security/privacy/) with complete telemetry table * **Contact** - for privacy questions, for security issues # Single Sign-On (SSO) Canonical page: [/enterprise/security-and-compliance/sso/](https://docs.warp.dev/enterprise/security-and-compliance/sso/) > Configure Single Sign-On (SSO) to authenticate and manage access to Warp across your organization. Warp uses SSO to authenticate users and control access to your organization’s Warp team. This guide covers configuring SSO, testing your setup, and managing user access through your identity provider. ## Supported identity providers [Section titled “Supported identity providers”](#supported-identity-providers) Warp supports the following identity providers: * **Okta** * **Microsoft Entra ID** * **Google Workspace** * **OneLogin** * **Any SAML 2.0 or OpenID Connect (OIDC) compatible provider** ## SSO enforcement and session management [Section titled “SSO enforcement and session management”](#sso-enforcement-and-session-management) * **SSO enforcement** - Admins can require SSO for all team members, preventing login via other methods. * **Multi-factor authentication** - MFA is enforced through your identity provider’s policies. Warp respects MFA requirements configured in Okta, Microsoft Entra ID, Google Workspace, etc. * **Session management** - Configurable session timeouts and re-authentication policies through your identity provider. ## Setting up SSO [Section titled “Setting up SSO”](#setting-up-sso) SSO is configured through [WorkOS](https://workos.com) in coordination with Warp’s team: 1. Contact your Warp account team or [enterprise support](https://www.warp.dev/contact-sales) to initiate SSO setup. 2. Warp creates an organization for your team in WorkOS and sets your team domain. 3. Your IT admin receives an email invite from WorkOS. 4. Follow the WorkOS setup wizard to connect your identity provider (configure SAML attributes or OAuth scopes, provide your SSO URL and certificate). 5. Once complete, team members can log in via **Continue with SSO** on the [Warp login page](https://app.warp.dev/login). ## Testing SSO [Section titled “Testing SSO”](#testing-sso) Before rolling out to your team: 1. Open an incognito/private browser window. 2. Navigate to the [Warp login page](https://app.warp.dev/login). 3. Click **Continue with SSO**. 4. Enter your organization’s domain. 5. Verify you’re redirected to your identity provider and can log in successfully. Caution Warp cannot be launched directly from your SSO provider’s app portal (e.g., Okta dashboard). Users must log in through the [Warp login page](https://app.warp.dev/login) and select **Continue with SSO**. ## SCIM provisioning [Section titled “SCIM provisioning”](#scim-provisioning) Warp supports SCIM for user lifecycle management. Provisioning works through Just-In-Time (JIT) provisioning combined with SSO and domain capture: * **User provisioning** - Add users to the Warp application in your identity provider. Once they sign in via SSO, they are automatically added to your Warp team. * **Domain auto-join** - Users who sign in with SSO from your configured domain are automatically joined to your team. See [Domain auto-join](#domain-auto-join) for setup details. * **User deprovisioning** - Removing a user from the Warp application in your identity provider prevents future SSO logins. Existing sessions are not immediately revoked. ## Linking existing accounts [Section titled “Linking existing accounts”](#linking-existing-accounts) Users who created a Warp account before your organization enabled SSO need to link their accounts: 1. Log in to Warp with the original method (email, Google, or GitHub). 2. Navigate to the [SSO linking page](https://app.warp.dev/link_sso). 3. Complete the linking process. 4. Log out and log back in with **Continue with SSO**. ## Domain auto-join [Section titled “Domain auto-join”](#domain-auto-join) Domain auto-join allows users from your organization to automatically join your Warp team after SSO authentication. Once your team domain is configured, users who sign in via SSO from your domain are automatically added to your Warp team. ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) ### Users can’t log in with SSO [Section titled “Users can’t log in with SSO”](#users-cant-log-in-with-sso) **Common causes:** * SSO not properly configured in your identity provider. * User trying to launch Warp directly from SSO provider (not supported). * User has an existing Warp account that needs to be [linked to SSO](https://app.warp.dev/link_sso). **Solution:** 1. Verify SSO configuration in your identity provider. 2. Have users log in through the [Warp login page](https://app.warp.dev/login) and select **Continue with SSO**. 3. For existing accounts, follow the [SSO linking process](https://app.warp.dev/link_sso). ### Warp won’t open from SSO provider portal [Section titled “Warp won’t open from SSO provider portal”](#warp-wont-open-from-sso-provider-portal) **Problem:** Clicking Warp in Okta/Microsoft Entra ID portal shows an error. **Solution:** Log in directly through the [Warp login page](https://app.warp.dev/login) and select **Continue with SSO** instead. ## Related resources [Section titled “Related resources”](#related-resources) * [Security overview](/enterprise/security-and-compliance/security-overview/) - Enterprise security posture and compliance * [Getting started for admins](/enterprise/getting-started/getting-started-enterprise/) - Full admin onboarding guide * [Troubleshooting login issues](/support-and-community/troubleshooting-and-support/troubleshooting-login-issues/) # Warp Trust Center Canonical page: [/enterprise/security-and-compliance/trust-center/](https://docs.warp.dev/enterprise/security-and-compliance/trust-center/) > Access Warp's security documentation, compliance certifications, and third-party assessment resources to complete your vendor security review. Warp’s [Trust Center](https://trust.warp.dev) is the central hub for security documentation, compliance certifications, and third-party assessments. It provides the information security teams, procurement, and compliance officers need to evaluate Warp as a vendor and complete security reviews. ## Compliance certifications [Section titled “Compliance certifications”](#compliance-certifications) ### SOC 2 Type II [Section titled “SOC 2 Type II”](#soc-2-type-ii) Warp is **SOC 2 Type II certified**, demonstrating compliance with industry-standard security controls across the following trust service criteria: * **Security** - Infrastructure protection, access controls, and monitoring * **Availability** - System uptime and disaster recovery * **Confidentiality** - Data protection and privacy controls * **Processing integrity** - Accurate, complete, and authorized processing **Requesting SOC 2 reports:** Enterprise customers can request SOC 2 reports directly through the [Trust Center portal](https://trust.warp.dev), through their account manager, or by emailing . ## Subprocessors [Section titled “Subprocessors”](#subprocessors) Warp publishes a list of subprocessors — third-party service providers that process data on Warp’s behalf. This includes infrastructure providers, LLM providers, and other services that support Warp’s operations. View the current list of subprocessors at [Warp subprocessors list](https://www.warp.dev/legal/subprocessors). ## Security documentation [Section titled “Security documentation”](#security-documentation) The following resources provide detailed information about Warp’s security practices: * **[Trust Center portal](https://trust.warp.dev)** - External portal with downloadable compliance reports and real-time security status * **[Security overview](/enterprise/security-and-compliance/security-overview/)** - Warp’s security architecture, data handling, and compliance certifications * **[Privacy policy](https://www.warp.dev/legal/privacy-policy)** - How Warp collects, uses, and protects personal data * **[Subprocessors](https://www.warp.dev/legal/subprocessors)** - Third-party service providers that process data on Warp’s behalf ## Requesting security information [Section titled “Requesting security information”](#requesting-security-information) If you’re conducting a vendor security assessment or completing a compliance questionnaire, Warp can provide: * **SOC 2 Type II reports** - Available upon request for Enterprise customers * **Compliance questionnaire assistance** - Warp’s security team can help complete vendor security questionnaires * **[Architecture and deployment](/enterprise/enterprise-features/architecture-and-deployment/)** - Details about Warp’s infrastructure, deployment models, and data flows To request any of these materials, contact your account manager or email . ## Penetration testing and vulnerability management [Section titled “Penetration testing and vulnerability management”](#penetration-testing-and-vulnerability-management) Warp conducts regular security assessments as part of its SOC 2 program. The details of Warp’s vulnerability management and penetration testing practices are validated through its SOC 2 Type II certification. ### Responsible disclosure [Section titled “Responsible disclosure”](#responsible-disclosure) If you discover a security vulnerability in Warp, please report it responsibly: 1. Email with detailed steps to reproduce the issue. 2. Allow Warp time to investigate and address the vulnerability before any public disclosure. Warp works with reporters to coordinate disclosure timelines. # Enterprise billing Canonical page: [/enterprise/support-and-resources/billing/](https://docs.warp.dev/enterprise/support-and-resources/billing/) > Learn about billing for Warp Enterprise, including credits, cloud agent costs, and billing management. This page covers general information about credits, cloud agent costs, and BYOLLM billing for enterprise teams. If you have specific questions about custom pricing, credit allocation, or contract terms, contact your Warp account manager. ## Credits [Section titled “Credits”](#credits) Warp uses a credit-based billing model. Any interaction with agents consumes credits based on the complexity of the task, the model used, and the amount of context processed. ### How credits work [Section titled “How credits work”](#how-credits-work) * Each agent interaction consumes **at least one credit**, though complex interactions may use multiple credits. * Credit usage is influenced by the LLM model used, the number of tool calls, task complexity, amount of context, and prompt caching behavior. * Credit usage is **non-deterministic**. Two similar prompts may consume different numbers of credits. For details on how credits are calculated, see [Credits](/support-and-community/plans-and-billing/credits/). ### Credit allocation [Section titled “Credit allocation”](#credit-allocation) Enterprise plans include a custom team-wide credit pool as part of your contract. Credits are primarily shared across the entire team rather than allocated per seat. Individual credit grants may also occur (e.g., support refunds), but the core allocation is team-wide. ## Cloud agent billing [Section titled “Cloud agent billing”](#cloud-agent-billing) Cloud agents consume AI credits for inference, compute credits for the sandbox they run in, and platform credits for the orchestration layer. See [Credits](/support-and-community/plans-and-billing/credits/) for the full breakdown of how each credit type is metered. ### How credits are consumed [Section titled “How credits are consumed”](#how-credits-are-consumed) On Enterprise plans, local and cloud agent usage both draw from the same team credit pool across all three credit types (AI credits, compute credits, and platform credits). The credit type a run consumes depends on what infrastructure it uses, not on whether it’s local or cloud. For agent API key runs (e.g., CI/CD pipelines, scheduled tasks), credits also draw from the team’s shared pool since these runs are not tied to any individual user. For more details, see [Access, Billing, and Identity](/agent-platform/cloud-agents/team-access-billing-and-identity/). ## BYOLLM billing [Section titled “BYOLLM billing”](#byollm-billing) When using [Bring Your Own LLM (BYOLLM)](/enterprise/enterprise-features/bring-your-own-llm/), Warp routes requests through your cloud infrastructure (AWS Bedrock today, with Azure Foundry and Google Vertex coming soon). BYOLLM requests **consume credits at a reduced rate** which is approximately 80% lower than standard usage. Inference costs are also billed directly to your cloud account. If a BYOLLM request fails and Warp falls back to a direct API model, that fallback request consumes Warp credits at the standard rate. ## Managing billing [Section titled “Managing billing”](#managing-billing) Your Warp account manager handles all billing for your Enterprise contract. Contact your account manager or dedicated Slack/Teams channel for: * Invoices and payment changes * Contract modifications * Credit allocation adjustments For urgent billing issues, email . ### Spending controls [Section titled “Spending controls”](#spending-controls) Administrators can configure monthly spending limits and receive alerts to prevent unexpected charges. Configure these controls in the [Warp Admin Panel](https://app.warp.dev/admin/) under the **Billing** tab. #### Monthly spending limits [Section titled “Monthly spending limits”](#monthly-spending-limits) Enterprise administrators can set monthly spending limits across the following four categories: * **Cloud spending limit** - Cap monthly spend on cloud agent usage. * **Local spending limit** - Cap monthly spend on local agent usage in the Warp app. * **Total spending limit** - Cap combined monthly spend across both cloud and local agents. * **Per-user spending limit** - Cap monthly spend for any individual user. Set a default that applies to all users, or configure limits on a per-user basis for predictable individual spend. Spending is tracked across all payment types (add-on credits, pay-as-you-go usage) so limits apply consistently regardless of how usage is funded. #### Monthly spend alerts [Section titled “Monthly spend alerts”](#monthly-spend-alerts) Warp sends alerts to administrators as team usage approaches each configured spending limit, so you can adjust caps, purchase more credits, or communicate with your team before agent usage is blocked at the cap. #### Credit pool depletion alerts [Section titled “Credit pool depletion alerts”](#credit-pool-depletion-alerts) For enterprises with credit pools, administrators receive alerts as the team credit pool approaches full consumption. This gives you time to top up your credits or change your reload configuration before agent usage is interrupted for the entire team. ## Related resources [Section titled “Related resources”](#related-resources) * [Credits](/support-and-community/plans-and-billing/credits/) - How credits are calculated and consumed * [Add-on credits](/support-and-community/plans-and-billing/add-on-credits/) - Purchase additional credits and configure auto-reload * [Platform credits](/support-and-community/plans-and-billing/platform-credits/) - The third credit bucket alongside AI credits and compute credits, covering Warp’s platform infrastructure * [Pricing FAQs](/support-and-community/plans-and-billing/pricing-faqs/) - Common billing questions * [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) - BYOLLM billing and configuration * [Enterprise Analytics API](/enterprise/enterprise-features/analytics-api/) - Programmatic access to team usage and spend data * [Admin Panel](/enterprise/team-management/admin-panel/) - Configure spending limits and billing settings # Feedback and feature requests Canonical page: [/enterprise/support-and-resources/feedback-and-feature-requests/](https://docs.warp.dev/enterprise/support-and-resources/feedback-and-feature-requests/) > Report bugs, request features, and get support as a Warp Enterprise customer. Warp Enterprise customers have access to dedicated support channels for reporting issues, requesting features, and getting help. This page explains how to reach the right team and provide the information needed to resolve issues quickly. ## Enterprise support channels [Section titled “Enterprise support channels”](#enterprise-support-channels) Enterprise customers receive **priority support** through dedicated channels: * **Dedicated Slack or Teams channel** - Your primary support channel. A private channel shared with Warp engineers for real-time assistance, bug reports, and feature discussions. * **Account manager** - Your direct contact for escalations, strategic feature requests, and enterprise-specific questions. ## Reporting bugs [Section titled “Reporting bugs”](#reporting-bugs) When reporting a bug, include the following to help Warp’s team investigate quickly: 1. **Description** - What happened and what you expected to happen. 2. **Steps to reproduce** - How to trigger the issue. 3. **Conversation ID** (for Agent issues) - Right-click on the Agent conversation block in question, select **Copy conversation ID**, and include it in your report. When an Agent conversation produces an error, an option to copy the conversation ID also appears inline. See [Gathering conversation ID](/support-and-community/troubleshooting-and-support/sending-us-feedback/#gathering-ai-conversation-id) for more details. 4. **Logs** (if relevant) - See [Gathering logs](#gathering-logs) below. 5. **Environment details** - OS, Warp version, and any relevant configuration. ### Gathering logs [Section titled “Gathering logs”](#gathering-logs) Warp’s logs do not contain console input or output. Log file locations by platform: * **macOS** - `~/Library/Logs/warp.log*` * **Windows** - `%LOCALAPPDATA%\warp\Warp\data\logs\warp.log*` * **Linux** - `~/.local/state/warp-terminal/warp.log*` You can also access logs directly in the app: open the **Command Palette** (`⌘P` on macOS / `Ctrl+Shift+P` on Windows/Linux) and search for **View Warp Logs**. For detailed log gathering instructions, including how to zip logs and capture crash reports, see [Sending Feedback & Logs](/support-and-community/troubleshooting-and-support/sending-us-feedback/). ## Requesting features [Section titled “Requesting features”](#requesting-features) To request a new feature or enhancement: * **Enterprise customers** - Share feature requests through your dedicated Slack/Teams channel or with your account manager. This ensures your request is tracked and prioritized by the product team. * **Public feature requests** - Open an issue on [GitHub Issues](https://github.com/warpdotdev/warp/issues/new/choose) for visibility and community discussion. ## Specialized contacts [Section titled “Specialized contacts”](#specialized-contacts) For security or privacy inquiries, reach out to the appropriate team directly: * **Security issues** - * **Privacy questions** - For all other inquiries — including billing, technical issues, and feature requests — contact your account manager or dedicated Slack/Teams channel. ## Related resources [Section titled “Related resources”](#related-resources) * [Troubleshooting login](/enterprise/support-and-resources/troubleshooting-login/) - Resolve login and SSO issues # Troubleshooting login Canonical page: [/enterprise/support-and-resources/troubleshooting-login/](https://docs.warp.dev/enterprise/support-and-resources/troubleshooting-login/) > Resolve common login and SSO issues for Warp Enterprise users and IT admins. This page covers common login issues for Warp Enterprise users, with a focus on SSO-related problems. For SSO setup and configuration, see [Single Sign-On (SSO)](/enterprise/security-and-compliance/sso/). ## SSO login issues [Section titled “SSO login issues”](#sso-login-issues) ### Can’t open Warp from your SSO provider [Section titled “Can’t open Warp from your SSO provider”](#cant-open-warp-from-your-sso-provider) When launching Warp directly from Okta or another SSO provider’s app dashboard, you may see an error like “Unable to process request due to missing initial state.” This is a known limitation with the authentication flow. **To fix it:** 1. Go to the [Warp login page](https://app.warp.dev/login). 2. Choose **Continue with SSO**. 3. Log in with your normal SSO credentials. ### Previously logged in with another method [Section titled “Previously logged in with another method”](#previously-logged-in-with-another-method) If you originally created your Warp account with email, Google, or GitHub and now need to use SSO: 1. Go to the [Warp login page](https://app.warp.dev/login). 2. Log in with your **original** method (email, Google, or GitHub). 3. Once logged in, visit the [SSO linking page](https://app.warp.dev/link_sso). 4. Click **Link SSO** to connect your existing account. You can now use **Continue with SSO** going forward. ## Common login issues [Section titled “Common login issues”](#common-login-issues) ### Can’t sign up or log in [Section titled “Can’t sign up or log in”](#cant-sign-up-or-log-in) If clicking the sign-up or login button opens a blank popup or nothing happens: * Your ISP or firewall may be blocking calls to `*.googleapis.com`. Try using a proxy or allowlisting this domain. * In some older Ruby development environments, `.dev` domains don’t resolve properly. If applicable, delete `/etc/resolver/dev` ([more info](https://superuser.com/questions/1374892/dev-domains-dont-resolve)). ### Browser-specific issues [Section titled “Browser-specific issues”](#browser-specific-issues) If you see authentication errors or blank popups across browsers: 1. **Disable ad blockers** for `app.warp.dev`. 2. **Clear cookies and cache**, or try an incognito / private browser window. 3. Try the [Warp login page](https://app.warp.dev/login) again. **Safari-specific:** If you see “Unable to access localStorage” errors, go to **Safari Preferences** > **Privacy** and uncheck **Block all cookies**. Firebase Auth requires cookies to track login state. ## Proxy issues [Section titled “Proxy issues”](#proxy-issues) If you’re behind a proxy, QUIC traffic may not pass through correctly. Disabling QUIC in your browser forces a fallback to TCP, which typically resolves the issue: **Chrome / Chromium-based browsers (Edge, Opera, Arc):** 1. Navigate to `chrome://flags`. 2. Search for **Experimental QUIC protocol**. 3. Set it to **Disabled**. 4. Relaunch the browser. **Firefox:** 1. Navigate to `about:config`. 2. Accept the risk warning. 3. Search for `network.http.http3.enable`. 4. Double-click to set it to `false`. 5. Restart Firefox. **Safari:** There is no built-in option to disable QUIC in Safari. ## Flagged as fraudulent [Section titled “Flagged as fraudulent”](#flagged-as-fraudulent) If you see “This account has been flagged as fraudulent,” your account has triggered Warp’s fraud detection system. This can happen due to multiple account creation or use of throwaway emails (both against Warp’s [Terms of Service](https://www.warp.dev/legal/terms-of-service)). ### False positives [Section titled “False positives”](#false-positives) Ad blockers or systems like Pi-hole can sometimes trigger false positives. Try temporarily disabling them and attempting login again. ### Requesting an appeal [Section titled “Requesting an appeal”](#requesting-an-appeal) If you’re still unable to authenticate, email with the email address of the affected account. Appeals may take 5–10 days. Enterprise customers can also contact their account manager or dedicated Slack/Teams channel for faster resolution. ## Browser doesn’t open when signing in [Section titled “Browser doesn’t open when signing in”](#browser-doesnt-open-when-signing-in) If the browser doesn’t open automatically from Warp when you click “Sign up” or “Sign in”: 1. Go to the [Signup](https://app.warp.dev/signup) or [Login](https://app.warp.dev/login) page in your browser. 2. Complete authentication in the browser. 3. On the logged-in page, if “Take me to Warp” doesn’t work, click the **here** link to copy the authentication token. 4. Paste the token into Warp. ## Getting help [Section titled “Getting help”](#getting-help) * **Enterprise customers** - Contact your dedicated Slack/Teams channel or account manager. * **All other users** - Visit the [Warp contact page](https://www.warp.dev/contact) for support. ## Related resources [Section titled “Related resources”](#related-resources) * [Single Sign-On (SSO)](/enterprise/security-and-compliance/sso/) - SSO setup and configuration * [Feedback and feature requests](/enterprise/support-and-resources/feedback-and-feature-requests/) - Report bugs and request features * [Troubleshooting login (full guide)](/support-and-community/troubleshooting-and-support/troubleshooting-login-issues/) - Complete troubleshooting reference # Admin Panel for teams Canonical page: [/enterprise/team-management/admin-panel/](https://docs.warp.dev/enterprise/team-management/admin-panel/) > Centralized management for team administrators to configure Warp settings, control agent behavior, and enforce security policies across your organization. The Admin Panel provides administrators with centralized control over team settings in Warp. Configure agent behavior, security policies, codebase indexing, and collaboration features for your entire organization from a single interface. ## What is the Admin Panel? [Section titled “What is the Admin Panel?”](#what-is-the-admin-panel) The [Admin Panel](https://app.warp.dev/admin/) is your control center for managing Warp at scale. It allows IT admins, platform teams, and engineering managers to: * **Control agent behavior** - Set autonomy levels, command permissions, and safety guardrails organization-wide * **Enforce security policies** - Configure secret redaction, telemetry controls, and data handling * **Manage team resources** - Enable Codebase Context, configure BYOLLM, and control sharing permissions * **Monitor usage** - Track credit consumption and set spending limits * **Maintain compliance** - Apply consistent policies that meet your organization’s security requirements ## Accessing the Admin Panel [Section titled “Accessing the Admin Panel”](#accessing-the-admin-panel) ### For team admins [Section titled “For team admins”](#for-team-admins) Access the Admin Panel in two ways: **Option 1: Direct URL** 1. Navigate to the [Warp Admin Panel](https://app.warp.dev/admin/). 2. Log in with your SSO credentials. 3. The Admin Panel opens with all organization settings. **Option 2: From Warp Settings** 1. Open Warp and click your profile icon in the top right. 2. Click **Settings**. 3. Navigate to the **Admin Panel** tab (visible only to team admins). ### For team members [Section titled “For team members”](#for-team-members) Team members see organization-enforced settings in their personal Settings panel: * Settings controlled by admins appear grayed out * Indicated by message: “Your organization has configured this setting” * Users retain control over settings where admins have selected “Respect User Setting” ## How settings enforcement works [Section titled “How settings enforcement works”](#how-settings-enforcement-works) The Admin Panel uses a three-tier enforcement model that keeps administrators in control while allowing appropriate flexibility. ### Setting enforcement levels [Section titled “Setting enforcement levels”](#setting-enforcement-levels) **Organization enforced** * Setting applies to all team members regardless of individual preferences * Users cannot override these settings * Use for security-critical policies (e.g., secret redaction, command denylists) **Respect user setting** * Allows individual team members to control the setting themselves * Admins set a default, but users can customize * Use for preferences that don’t impact security or compliance (e.g., AI model selection) **Tier restricted** * Setting is locked based on billing plan * Cannot be changed until plan is upgraded * Indicated by message: “Configuring this setting is not available on your plan” ### Testing before enforcement [Section titled “Testing before enforcement”](#testing-before-enforcement) To safely roll out new policies: 1. Configure settings with “Respect User Setting” initially. 2. Test with a small group of users. 3. Gather feedback and adjust configuration. 4. Switch to “Organization enforced” once validated. ## Plan limitations [Section titled “Plan limitations”](#plan-limitations) The features available in the Admin Panel scale with your Warp plan: ### Free tier [Section titled “Free tier”](#free-tier) * Most settings are fixed and non-configurable * Limited Codebase Context (2 repositories) * No BYOLLM support * Basic sharing features ### Business plans [Section titled “Business plans”](#business-plans) * Most settings become configurable by administrators * Enhanced agent autonomy control * Advanced sharing and privacy features * Increased Codebase Context limits ### Enterprise plans [Section titled “Enterprise plans”](#enterprise-plans) * **Full admin control** - Configure all available settings * **Enterprise secret redaction** - Custom regex patterns for secrets * **BYOLLM** - Route inference through your cloud infrastructure * **Self-hosting cloud agent workers** - Deploy cloud agent workers on your own infrastructure * **Advanced compliance** - SOC 2, HIPAA, and custom data handling agreements * **Priority support** - Dedicated Slack/Teams channels For complete plan details, see [Warp pricing](https://www.warp.dev/pricing) or [contact sales](https://www.warp.dev/contact-sales). ## Admin Panel sections [Section titled “Admin Panel sections”](#admin-panel-sections) The Admin Panel is organized into six main areas: ### AI settings [Section titled “AI settings”](#ai-settings) Configure how agents behave across your organization, including autonomy levels and command permissions. This is where you balance agent productivity with organizational safety requirements. #### General AI settings [Section titled “General AI settings”](#general-ai-settings) **AI in remote sessions** * Controls whether agents are available during SSH sessions and remote connections * Enterprise plans can toggle this setting * Consider disabling for production servers or sensitive environments **Prompt summarization caching** * When conversations become long, the LLM provider caches summaries temporarily * Improves performance for extended agent interactions * Zero Data Retention agreements cover caching (short-lived) #### Autonomy settings [Section titled “Autonomy settings”](#autonomy-settings) Configure how much independence agents have when performing actions. Choose between: * **Agent Decides** - Agent acts autonomously when confident, asks when uncertain (recommended) * **Always Ask** - Require explicit approval for every action * **Always Allow** - Maximum autonomy without confirmations * **Respect User Setting** - Allow individual users to set their preference **Apply code diffs** Controls whether agents can apply code changes without approval. For production-critical codebases, consider “Always Ask” to maintain tight control. **Create plans** Whether agents can create structured task plans (`/plan` command) without user approval. **Execute commands** Manages the agent’s ability to run terminal commands autonomously. Pair with command allowlists/denylists for granular control. **Read files** Controls agent access to reading files in the codebase. Enable for better context, restrict for sensitive repositories. #### Directory and command control [Section titled “Directory and command control”](#directory-and-command-control) **Directory allowlist** Specify directories where agents can read files without restriction. Use absolute paths: * `~/git/internal-tooling` - Grant access to specific projects * `/home/user/repos/public-*` - Use wildcards for patterns **Command allowlist** Regular expressions matching commands agents can execute without asking permission. Common patterns: * `grep .*` - Text search * `ls(\\s.*)?` - Directory listing * `git status` - Version control queries * `which .*` - Finding executables **Command denylist** Regular expressions for commands that **always** require explicit user approval, regardless of autonomy settings: * `rm -rf.*` - Recursive deletion * `sudo.*` - Administrative commands * `curl.*|wget.*` - Network requests * `docker rm.*` - Container operations * `.*production.*` - Commands containing “production” Caution Command denylist rules take precedence over allowlist rules and agent autonomy settings. Use denylists to prevent high-risk operations even in high-autonomy configurations. ### Privacy settings [Section titled “Privacy settings”](#privacy-settings) Manage data collection and security policies to meet your organization’s compliance requirements. **User-generated content (UGC) data collection** Controls how Warp collects and uses user-generated content to improve the service: * **Disabled** - Warp collects no UGC data from your organization * **Enabled** - Allow data collection for service improvement * **Respect User Setting** - Let individual users decide Enterprise teams with Zero Data Retention agreements can disable this completely. **Enterprise secret redaction** Automatically detects and redacts sensitive information before sending data to LLM providers: * Enterprise plans enable this by default * Includes automatic detection of common secret patterns (API keys, passwords, certificates) * Supports custom regex patterns for organization-specific secrets * Applies unconditionally across all team members Configure custom patterns in the Admin Panel to match your organization’s secret formats. ### Code settings [Section titled “Code settings”](#code-settings) Control codebase indexing and agent code features for your team. **Codebase Context** Determines whether Warp indexes your team’s Git repositories to provide context for agents: * **Disabled** - No codebase indexing * **Enabled** - Index codebases for improved agent responses across large, multi-repo systems * **Respect User Setting** - Allow individual control When enabled, agents understand your code patterns, architecture, and conventions across all indexed repositories. Enterprise plans support: * Unlimited repositories * Up to 200,000 files per repository * Team-wide indexing with centralized configuration ### Billing settings [Section titled “Billing settings”](#billing-settings) Configure billing preferences and spending controls to manage costs at scale. **Usage-based pricing** Enable pay-as-you-go billing for credits beyond your plan’s included quota: * Set monthly spending limits to control costs * View current overage usage and costs * Receive alerts when approaching spending thresholds **Credit allocation** For Enterprise plans with negotiated credit pools: * Allocate credits across teams or projects * Monitor usage by team * Set per-team spending limits Contact your account manager to configure advanced credit allocation. ### Sharing settings [Section titled “Sharing settings”](#sharing-settings) Control how team members collaborate and share Warp Drive resources. **Direct link sharing** Allow team members to share Notebooks, Workflows, Prompts, and other Warp Drive objects via direct links: * **Enabled** - Team members can generate shareable links * **Team only** - Links work only for team members * **Disabled** - No link sharing **Anyone with link sharing** Enable public access to shared objects: * **Enabled** - Anyone with the link can view content without being a team member * **Disabled** - Links require team membership to access For organizations with sensitive internal processes, disable “Anyone with link” sharing to prevent accidental exposure. ### Platform settings [Section titled “Platform settings”](#platform-settings) Configure cloud agent settings for your team, including GitHub authorization for automated workflows. **Enabled GitHub Orgs** The **Enabled GitHub Orgs** setting associates your Warp team with one or more GitHub App installations, enabling cloud agents initiated with an [agent API key](/reference/cli/api-keys/) to clone repositories and open pull requests using the Oz by Warp GitHub App. To configure: 1. Navigate to the **Platform** section of the Admin Panel. 2. Under **Enabled GitHub Orgs**, review the list of GitHub organizations where the Oz by Warp GitHub App is installed. 3. Select which organizations your team should have access to.  Enabled GitHub Orgs setting in the Admin Panel. The organizations and repository access shown here reflect the Oz by Warp GitHub App installation scope, which is configured in [GitHub settings](https://github.com/settings/installations). To change which repositories the app can access, edit the installation directly in GitHub. ## Multi-admin functionality [Section titled “Multi-admin functionality”](#multi-admin-functionality) Warp supports multiple team administrators to prevent single points of failure and enable distributed management. ### Promoting and demoting admins [Section titled “Promoting and demoting admins”](#promoting-and-demoting-admins) Team admins can grant or revoke admin privileges: 1. Navigate to **Settings** > **Teams** > **Team Members**. 2. Find the user you want to modify. 3. Click the role dropdown next to their name. 4. Select **Admin** or **Member**. 5. Click **Save**. ## Common admin workflows [Section titled “Common admin workflows”](#common-admin-workflows) ### Initial enterprise setup [Section titled “Initial enterprise setup”](#initial-enterprise-setup) After purchasing a Warp enterprise plan: 1. **Configure SSO** - Set up authentication with your identity provider. 2. **Enable Codebase Context** - Index your organization’s repositories. 3. **Set agent autonomy** - Configure initial safety levels. 4. **Apply secret redaction** - Add custom patterns for your organization. 5. **Configure BYOLLM** (optional) - Route inference through your cloud accounts. 6. **Create shared resources** - Populate team Warp Drive with Workflows, Rules, and Prompts. See [Roles and permissions](/enterprise/team-management/roles-and-permissions/) for details on user roles and access controls. ### Adjusting policies for different teams [Section titled “Adjusting policies for different teams”](#adjusting-policies-for-different-teams) For organizations with multiple teams (e.g., DevOps, Data, Frontend): 1. Create separate Warp teams for each group. 2. Assign team-specific admins. 3. Configure different autonomy levels per team. 4. Use directory allowlists to scope agent access to team repositories. ### Responding to security incidents [Section titled “Responding to security incidents”](#responding-to-security-incidents) If an agent performs an unintended action: 1. **Immediate:** Review agent action logs in the affected user’s session. 2. **Short-term:** Add specific commands to the command denylist. 3. **Long-term:** Adjust autonomy settings to prevent similar incidents. 4. **Review:** Check the Admin Panel settings for the affected user’s team to confirm what autonomy levels, allowlists, and restrictions were in effect. Warp logs all agent actions with full context, making incident investigation straightforward. ## Troubleshooting [Section titled “Troubleshooting”](#troubleshooting) ### Users can’t see new settings [Section titled “Users can’t see new settings”](#users-cant-see-new-settings) **Problem:** You changed a setting in the Admin Panel, but users report they don’t see the change. **Solution:** 1. Verify the setting is not set to “Respect User Setting”. 2. Ask users to restart Warp to force a settings refresh. 3. Confirm users are members of the correct team. 4. Check that users have logged in with SSO (not a personal account). ### Setting is grayed out in Admin Panel [Section titled “Setting is grayed out in Admin Panel”](#setting-is-grayed-out-in-admin-panel) **Problem:** A setting you want to configure appears grayed out or shows “Not available on your plan.” **Solution:** * This setting is restricted to higher-tier plans * Review plan features on [Warp pricing](https://www.warp.dev/pricing) * Contact your account manager or [sales team](https://www.warp.dev/contact-sales) to upgrade ### Command allowlist not working [Section titled “Command allowlist not working”](#command-allowlist-not-working) **Problem:** Agents still ask permission for commands that match your allowlist patterns. **Solution:** 1. Verify regex patterns are correct (test with a regex validator). 2. Check that commands don’t also match the denylist (denylist takes precedence). 3. Confirm autonomy settings allow command execution. 4. Remember: Some commands are always restricted regardless of allowlist. ## Support [Section titled “Support”](#support) Enterprise customers have access to priority support: * **Dedicated channels** - Private Slack or Teams channels with Warp engineers * **Account manager** - Direct contact for escalations and feature requests * **Technical support** - Help with Admin Panel configuration and troubleshooting Reach out through your dedicated Slack/Teams channel or contact your account manager. # Roles and permissions Canonical page: [/enterprise/team-management/roles-and-permissions/](https://docs.warp.dev/enterprise/team-management/roles-and-permissions/) > Understand user roles, permissions, and access controls for managing your Warp Enterprise team. Warp uses a role-based access model to control what team members can do within your organization. Admins manage team settings and enforce policies, while members use Warp’s features within the boundaries admins define. ## User roles [Section titled “User roles”](#user-roles) Warp has three user roles: * **Team Owner** - Has full access to the Admin Panel and can manage team settings, invite users, assign roles, and transfer ownership of the team. There can only be one Owner. * **Team Admin** - Same permissions as the Owner, except they can’t transfer ownership of the team. * **Member** - Standard access to Warp features and team resources. Members can use agents, access shared Warp Drive resources, and configure personal settings within the limits set by admins. ## Managing admins [Section titled “Managing admins”](#managing-admins) Teams can have multiple admins. We recommend at least one admin in addition to the Team Owner to prevent access issues if one is unavailable. ### Promoting or demoting admins [Section titled “Promoting or demoting admins”](#promoting-or-demoting-admins) 1. Navigate to **Settings** > **Teams** > **Team Members**. 2. Find the user you want to modify. 3. Click the three-dot menu icon next to their name. 4. Select **Promote to Admin** or **Demote from Admin**. 5. Confirm the change when prompted. Caution Team Admins cannot demote or modify the Team Owner role. ## Permission details [Section titled “Permission details”](#permission-details) ### What admins can do [Section titled “What admins can do”](#what-admins-can-do) * **Team management** - View members, invite users, remove users, and assign roles. * **Authentication** - Configure SSO and login requirements. * **Agent policies** - Set autonomy levels, command allowlists/denylists, and directory access controls. * **Security settings** - Configure secret redaction, telemetry controls, and data handling policies. * **Feature controls** - Enable or disable Codebase Context, BYOLLM, sharing, and other features. * **Billing** - Monitor credit usage, set spending limits, and manage subscriptions. ### What members can do [Section titled “What members can do”](#what-members-can-do) * **Use agents** - Run agents locally and in the cloud within the policies admins define. * **Access team resources** - Use shared Workflows, Notebooks, Prompts, Rules, and Environment Variables in Warp Drive. * **Configure personal settings** - Adjust settings where admins have selected “Respect User Setting.” * **Share sessions** - Collaborate via session sharing (if enabled by admins). * **Index codebases** - Trigger Codebase Context indexing for repositories (if enabled by admins). ### Settings enforcement [Section titled “Settings enforcement”](#settings-enforcement) Admin-configured settings follow a three-tier model: * **Organization enforced** - Applies to all members. Users cannot override these settings. Use for security-critical policies (e.g., secret redaction, command denylists). * **Respect user setting** - Admins set a default, but individual users can customize. Use for preferences that don’t impact security. * **Tier restricted** - Setting is locked based on billing plan and cannot be changed until the plan is upgraded. See the [Admin Panel](/enterprise/team-management/admin-panel/) documentation for details on configuring each setting. ## Resource sharing controls [Section titled “Resource sharing controls”](#resource-sharing-controls) Admins control how team members collaborate and share Warp Drive resources: * **Direct link sharing** - Allow team members to share Notebooks, Workflows, Prompts, and other objects via direct links. * **Team-only links** - Restrict links so only team members can access them. * **Public link sharing** - Enable or disable access for anyone with the link (even non-team members). For organizations with sensitive internal processes, disable public link sharing to prevent accidental exposure. ## Related resources [Section titled “Related resources”](#related-resources) * [Admin Panel](/enterprise/team-management/admin-panel/) - Configure team settings and enforce policies * [Getting started for developers](/enterprise/getting-started/getting-started-developers/) - Developer onboarding guide # Team management in Warp Canonical page: [/enterprise/team-management/teams/](https://docs.warp.dev/enterprise/team-management/teams/) > Create and manage teams in Warp to organize users, share resources, and collaborate across your engineering organization. ## What is a team? [Section titled “What is a team?”](#what-is-a-team) A team is a group of Warp users who collaborate together. Teams share a dedicated workspace in [Warp Drive](/knowledge-and-collaboration/warp-drive/), giving members access to shared Workflows, Notebooks, Prompts, Rules, Plans, and Environment Variables. Teams are the foundation of Warp’s enterprise experience — they enable centralized administration, shared configuration, and team-wide policy enforcement through the [Admin Panel](/enterprise/team-management/admin-panel/). ## Creating a team [Section titled “Creating a team”](#creating-a-team) You can create a new team in two ways: * From the **Warp Drive** side panel, click **+ Create a team**. * In Warp, navigate to **Settings** > **Teams** and follow the prompts. When creating a team, give it a meaningful name that represents your organization, company, or project. The person who creates the team becomes the **Team Owner**. ### Inviting team members [Section titled “Inviting team members”](#inviting-team-members) Under **Settings** > **Teams**, copy the invite link and share it with your teammates through a secure channel like Slack or email. Caution On paid plans, adding new members automatically adds them as paid seats. New members are billed on a prorated basis for the remainder of the billing cycle. See [Billing](/enterprise/support-and-resources/billing/) for details. ## Restricting team invites by domain [Section titled “Restricting team invites by domain”](#restricting-team-invites-by-domain) Team Admins can restrict team membership to users with specific email domains — for example, your company’s email domain. To enable domain restriction: 1. Navigate to **Settings** > **Teams**. 2. Toggle on **Restrict by domain**. 3. Add your allowed email domains to the allowlist. When domain restriction is enabled, users who attempt to join with a non-matching email domain will be prompted to authenticate via an emailed link sent to an email address on an allowed domain. ## Joining a team [Section titled “Joining a team”](#joining-a-team) If you’ve received an invite link, use it to sign up or log in and join the team. If the team uses domain restriction, you’ll need to verify that you have access to an email address on an allowed domain before joining. ## Leaving and deleting teams [Section titled “Leaving and deleting teams”](#leaving-and-deleting-teams) * **Members and Admins** - Can leave a team at any time by visiting **Settings** > **Teams** and clicking **Leave team**. * **Team Owners** - Can delete a team, but only after removing all other team members first. Caution If you’re a Team Owner and choose to [delete your Warp account](/support-and-community/privacy-and-security/privacy/#delete-your-account-and-data), you’ll need to assign a team member as the new owner before your account can be deleted. ### Add-on credit consequences when leaving or removing members [Section titled “Add-on credit consequences when leaving or removing members”](#add-on-credit-consequences-when-leaving-or-removing-members) On Build, Max, and Business plans, [add-on credits](/support-and-community/plans-and-billing/add-on-credits/) are scoped to each individual user but **tied to the team** they were purchased under. Membership changes affect access: * **A user leaves a team** - You lose access to any add-on credits tied to that team. If you rejoin the same team later, you regain access to any unused, non-expired credits. The admin pays a prorated rate for your seat on rejoin. * **An admin removes a member** - That member loses access to any add-on credits tied to the team. If they rejoin later, they regain access to any unused, non-expired credits. The admin pays a prorated rate for the seat when the user rejoins. * **An admin deletes the team** - Any remaining add-on credits tied to the team are no longer usable. Add-on credits require an active subscription. Downgrading to the Free plan forfeits access to add-on credits tied to your team. ## Team discoverability [Section titled “Team discoverability”](#team-discoverability) Team admins can make their team discoverable to colleagues who share the same email domain. When enabled, new users with a matching domain can find and join the team without needing a direct invite link. To enable discoverability, go to **Settings** > **Teams** > **Make team discoverable**. ## Transferring team ownership [Section titled “Transferring team ownership”](#transferring-team-ownership) Team Owners can transfer ownership to another team member: 1. Navigate to **Settings** > **Teams** > **Team Members**. 2. Click the three-dot menu icon next to the member you want to transfer ownership to. 3. Click **Transfer ownership**. Only the current Team Owner can initiate an ownership transfer. After the transfer, the previous owner becomes a regular member (or admin, depending on the team’s configuration). ## Team roles and permissions [Section titled “Team roles and permissions”](#team-roles-and-permissions) Warp uses three roles to manage team access: * **Team Owner** - Full access to the Admin Panel and all team settings. Can manage members, assign roles, configure policies, and transfer ownership. There can only be one Owner per team. * **Team Admin** - Same permissions as the Owner, except they cannot transfer team ownership. Teams on Enterprise plans can have multiple admins. * **Member** - Standard access to Warp features and team resources. Members can use agents, access shared Warp Drive resources, and configure personal settings within the limits set by admins. ### Permissions overview [Section titled “Permissions overview”](#permissions-overview) | Action | Owner | Admin | Member | | ------------------------------ | ----- | ----- | ------ | | Create a team | ✓ | ✓ | ✓ | | Restrict invites by domain | ✓ | ✓ | | | Invite members | ✓ | ✓ | ✓ | | Remove team members | ✓ | ✓ | | | Leave a team | | ✓ | ✓ | | Delete a team | ✓ | | | | Transfer ownership | ✓ | | | | Promote/demote admins | ✓ | ✓ | | | Manage billing | ✓ | ✓ | | | Configure Admin Panel settings | ✓ | ✓ | | ### Multi-admin support [Section titled “Multi-admin support”](#multi-admin-support) Teams on the **Enterprise** plan can have multiple admins, enabling distributed management and preventing single points of failure. To promote or demote a team admin: 1. Navigate to **Settings** > **Teams** > **Team Members**. 2. Find the user you want to modify and click the three-dot menu icon next to their name. 3. Click **Promote to Admin** or **Demote from Admin**. 4. Confirm the change when prompted. Caution Team Admins cannot demote or modify the Team Owner’s role. The Owner role can only change through an ownership transfer. For detailed information on what each role can do and how settings enforcement works, see [Roles and permissions](/enterprise/team-management/roles-and-permissions/). ## Related resources [Section titled “Related resources”](#related-resources) * [Admin Panel](/enterprise/team-management/admin-panel/) - Configure team settings and enforce policies * [Roles and permissions](/enterprise/team-management/roles-and-permissions/) - Detailed permission breakdowns and settings enforcement * [Getting started for admins](/enterprise/getting-started/getting-started-enterprise/) - Admin onboarding guide * [Billing](/enterprise/support-and-resources/billing/) - Understand team billing and seat management