No offline mode: client keeps persistent connections to app.warp.dev when logged out with all privacy settings off

[one-kash]

Summary

There is no setting to stop Warp's background connections to its servers. Even when logged out, with telemetry, crash reporting, AI, and settings sync all disabled, the client holds two persistent TLS connections open to app.warp.dev. No privacy setting, the Warp Drive toggle, or logging out fully closes them.

Observed behavior

macOS, Stable channel, 2026-08-27. Connections to Warp's backend at 34.117.41.85 (which app.warp.dev, rtc.app.warp.dev, oz.warp.dev, and sessions.app.warp.dev all resolve to) across states, with telemetry_enabled, crash_reporting_enabled, is_any_ai_enabled, and is_settings_sync_enabled all false:

State	Persistent connections to app.warp.dev
Logged in, Warp Drive on	3 (including the realtime subscription socket)
warp_drive.enabled set to false (hot-reload)	3 (no change)
Logged out	2 (realtime socket dropped, two remain)

The two remaining connections stayed established and active across repeated samples.

Where

The persistent connection is opened by the cloud-object sync layer, which subscribes over a websocket to the GraphQL endpoint:

warp/app/src/server/server_api/object.rs

Lines 655 to 691 in ead591e

	/// Starts a websocket connections against the corresponding GraphQL subscription.
	/// Messages received over the socket are sent over the `message_sender`.
	/// Once the websocket is live, a one-shot message is sent over `stream_ready_sender`
	/// to indicate so. This is because this method only returns once the websocket is closed.
	async fn get_warp_drive_updates(
	&self,
	message_sender: Sender<ObjectUpdateMessage>,
	stream_ready_sender: Sender<()>,
	) -> Result<()> {
	// The init payload is how we convey any metadata about
	// the subscription to the server (i.e. in lieu of http headers).
	// TODO (written by Suraj): we should consider consolidating the places we
	// supply this common data. GQL subscriptions use a different
	// implementation from our general server requests (which make
	// use of [`crate::http`]).
	let mut init_payload = HashMap::new();
	// Add the bearer token to the init payload when using header-based auth.
	// Session-cookie-authenticated clients rely on the websocket handshake cookies instead.
	let auth_token = self.get_or_refresh_access_token().await?;
	if let Some(token) = auth_token.as_bearer_token() {
	let bearer_token = format!("Bearer {token}");
	init_payload.insert(http_client::AUTHORIZATION.as_str(), bearer_token);
	}
	// Add the app version, if available.
	if let Some(app_version) = ChannelState::app_version() {
	init_payload.insert(
	http_client::headers::CLIENT_RELEASE_VERSION_HEADER_KEY,
	app_version.to_string(),
	);
	}
	let subscription = GetWarpDriveUpdates::build(());
	let result = start_graphql_streaming_operation(
	&ChannelState::ws_server_url(),

No offline, network-disable, or work-offline setting exists in the settings definitions (app/src/settings/*, crates/settings). The privacy settings only gate telemetry, crash reporting, and cloud conversation storage.

The onboarding copy states that non-cloud features work offline:

warp/app/src/auth/auth_view_shared_helpers.rs

Lines 172 to 174 in ead591e

	let paragraph_2 = "However, we require users to be online when using Warp for the first time in order to enable Warp's AI and cloud features.";
	let paragraph_3 = "We offer cloud features to all users, and so we need an internet connection to meter AI usage, prevent abuse, and associate cloud objects with users. If you opt to use Warp logged-out, a unique ID will be attached to an anonymous user account in order to support these features.";

In practice the client keeps connections open regardless of whether cloud features are in use.

Expected

Provide an offline mode, or a setting to stop background connections to Warp servers when the user has opted out of cloud features and AI. If some connection is required, document what it is and why it cannot be disabled, so the "works offline" statement is accurate.

Caveats for accuracy

Observed live within one running process; logging out tore down one socket in real time, so this is not a cold-start test. The four *.warp.dev hostnames share the GCP load-balancer IP 34.117.41.85, so I did not separate the two remaining connections by hostname without a root-level SNI capture. Read from the open-source client at commit ead591e.

[warp-for-oss]

@one-kash

Here's what I found while triaging this issue:

The current client appears to provide separate privacy and cloud-feature controls, but not a single offline/network-disable mode. Disabling Warp Drive does not appear to guarantee that all Warp backend connections are closed.

I have a few follow-up questions before I can narrow this down:

1. After fully quitting and relaunching Warp while logged out, do the same two Warp backend connections appear before using any cloud, AI, or Warp Drive feature?
2. What exact Warp Stable version/build was used for the network capture?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that warp currently lacks a global offline/network-disable mode, and the report provides plausible evidence that backend connections can remain after privacy/cloud toggles and logout state changes..

Initial triage

This looks like a request for a global offline/network-disable mode, backed by concrete observations of remaining Warp backend connections after disabling privacy/cloud-related settings and logging out. Current client code supports the reporter's claim that these controls are separate: privacy settings cover telemetry, crash reporting, and cloud conversation storage; settings sync has its own account setting; and the Warp Drive setting controls Warp Drive availability/visibility rather than all backend traffic.

Code evidence

• app/src/settings/privacy.rs defines telemetry, crash reporting, and cloud conversation storage settings, but not a global offline or no-network mode.
• app/src/settings/cloud_preferences.rs defines account.is_settings_sync_enabled; this is limited to cloud preference sync.
• app/src/drive/settings.rs defines warp_drive.enabled as whether Warp Drive is enabled/available in the UI and command surfaces, not as a transport shutdown setting.
• app/src/server/cloud_objects/listener.rs starts and retries the Warp Drive update websocket based on cloud-object/team state and network online/offline status, not the privacy toggles.
• app/src/auth/mod.rs clears auth/cloud state and stops polling/shared-session flows on logout, but the codebase does not expose a single app-wide mechanism that closes all Warp server transports or prevents all future backend requests.
• app/src/server/server_api.rs, crates/warp_server_client/src/base_client.rs, and crates/warp_core/src/channel/config.rs show the shared server client and production backend endpoints used by multiple features.

This supports the product gap/root-cause hypothesis, but it does not conclusively identify the two post-logout sockets without a cold-start logged-out capture or per-host/service attribution.

Duplicate check

I checked open issues across the repository and recent closed issues. Related issues include #15598 (warp_drive.enabled not stopping the Warp Drive realtime connection), #15596 (no setting for the auto-update version check), and #15595 (telemetry opt-out interaction with a server-controlled experiment flag), but fewer than two issues match this report's specific logged-out persistent app.warp.dev connection behavior closely enough to mark it as a duplicate under the repository dedupe rule.

Remaining ambiguity

The key uncertainty is whether the two logged-out connections are opened on a fresh logged-out launch or are idle/lingering transports from prior authenticated/cloud activity in the same process. The exact Stable build is also needed to tie the behavior to a release.

Question reasoning

1. After fully quitting and relaunching Warp while logged out, do the same two Warp backend connections appear before using any cloud, AI, or Warp Drive feature? — This distinguishes a logged-out startup behavior from idle or lingering connections left over after prior logged-in/cloud activity in the same process.
2. What exact Warp Stable version/build was used for the network capture? — The report gives the channel and date but not the build string, which is needed to tie the behavior to a specific released client version.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[one-kash]

Thanks for the questions. I ran the cold-start test, and it changes the conclusion. I want to correct the record.

1. On a fresh logged-out launch, before using any cloud, AI, or Warp Drive feature: no connections appear. After fully quitting and relaunching while logged out, the client made zero external connections and moved 0 bytes (per nettop), sustained across ~7 minutes idle at the welcome/login state.

So the two app.warp.dev connections in the original report were lingering transports left over from the prior logged-in session in the same process, not connections opened on a fresh logged-out launch. Observed sequence, same machine:

State	Connections to app.warp.dev
Logged in	2-3
Logged out, same process still running	2 (residual, not torn down)
Cold start, logged out, idle	0 (0 bytes)

That means the specific behavior this issue claims, persistent backend connections while logged out, does not reproduce on a clean start. Logout after a restart does stop them. The premise of this issue is wrong, and it should be reframed or closed.

The milder point from your own triage still stands: there is no single global offline/network-disable mode, and the privacy, sync, and Warp Drive controls are separate. But that is a smaller product-gap observation than what this issue states, and it overlaps with #15598.

2. Build: Warp Stable v0.2026.08.19.08.15.01 (dev.warp.Warp-Stable), macOS.

One caveat: the cold-start observation is idle at the login/welcome screen. I have not yet tested proceeding logged-out and actively using a terminal, which is the state that showed connections earlier. If that matters for triage, I can capture it.

[warp-for-oss]

@one-kash

Here's what I found while triaging this issue:

Thanks for the cold-start follow-up. This no longer looks like Warp opens backend connections on a fresh logged-out idle launch; the remaining actionable gap is that transports started while logged in may not be fully torn down on logout, and there is still no single offline/network-disable setting. This overlaps with #15598.

Maintainer details

I concluded that fresh logged-out cold start now appears to make no backend connections, but same-process logout may leave prior cloud transports alive and Warp still lacks a global offline/network-disable mode..

Triage summary

Thanks for the correction in the follow-up. The fresh logged-out cold-start case changes the issue substantially: this no longer appears to be evidence that Warp opens backend connections while sitting idle at the logged-out welcome screen.

The remaining actionable behavior is narrower and mixed bug/enhancement:

• Possible bug: after a logged-in session has already started cloud-object transports, logging out in the same process may not fully tear those transports down. The logout path resets auth state, cloud models, sync queues, and polling managers, but I did not find an explicit stop/reset for the cloud-object listener itself.
• Enhancement/product gap: there is no single global offline or network-disable mode. warp_drive.enabled controls Warp Drive availability/visibility, and privacy settings gate telemetry, crash reporting, and cloud conversation storage, but they do not promise to close every backend transport.

Code notes

• app/src/server/cloud_objects/listener.rs starts the Warp Drive update websocket when the user has team/cloud-object state. Its comment says that once websockets start, they are not stopped, and the model tracks should_subscribe_to_updates plus current_subscription_abort_handle.
• app/src/server/server_api/object.rs implements get_warp_drive_updates using the GraphQL streaming operation against ChannelState::ws_server_url().
• app/src/auth/mod.rs logout clears auth state, removes persisted settings, resets cloud models/managers, stops object/workspace metadata polling, and stops shared sessions, but it does not appear to call a listener teardown method.
• app/src/drive/settings.rs makes warp_drive.enabled a UI/availability setting and returns false for anonymous/logged-out users, but that setting is not a network kill switch.
• app/src/settings/privacy.rs defines the privacy toggles for telemetry, crash reporting, and cloud conversation storage; they are not modeled as a global offline mode.

Duplicate check

I enumerated open non-PR issues across the repository. #15598 is a strong overlap for the warp_drive.enabled/realtime-connection portion. #13894 is related to persistent outbound connections and disclosure, but it is broader and Windows-specific rather than the same logout/offline-mode behavior. Because the required duplicate workflow needs at least two likely duplicate issues, I am not marking this as a duplicate.

Suggested next step

Reframe this issue away from "fresh logged-out Warp opens persistent connections" and toward either (1) explicit teardown of already-started cloud transports on logout, or (2) a product decision/documentation update for whether Warp should offer a global offline/network-disable mode.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[one-kash]

Follow-up: I said I would capture the logged-out active-use case, so here it is.

Same machine, Stable v0.2026.08.19.08.15.01, logged out, with telemetry, crash reporting, AI, settings sync, and Warp Drive all off.

Logged-out state	Connections to app.warp.dev
Cold start, idle (7 min)	0
Cold start, then actively using the terminal	1 (opened ~56s in, then persists idle)

Details of the connection that appeared during use: one established socket to 34.117.41.85:443 (app.warp.dev), with the byte counters flat after it opened (about 3.4 KB in, 1.1 KB out total), so it is an idle keep-alive rather than active streaming. No connection to the RudderStack or Sentry endpoints in any state, so telemetry and crash opt-outs held.

Interpretation: idle logged-out Warp is silent. Using the terminal opens one low-traffic connection to app.warp.dev. The timing (0 for 7 minutes idle, then a socket once I started interacting) points to activity-gated behavior, not a cloud, AI, or Warp Drive feature, since those are all disabled. I cannot attribute it to a specific request without a per-host SNI capture.

Net: this is narrower than the issue as originally filed. Logged-out is not "persistently connected"; it is quiet when idle and opens one connection on use. The two connections in the first report were residual from the prior logged-in session. Reframe or close as you see fit.

[warp-for-oss]

@one-kash

Here's what I found while triaging this issue:

The follow-up narrows this: a fresh logged-out idle launch appears silent, and the remaining case is one low-traffic app.warp.dev connection after active terminal use. Warp currently documents that there is no explicit Offline Mode, so this is best framed as a request for a global network-disable/offline control or clearer disclosure of which logged-out requests can still occur.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a redacted Warp Network Log capture from a fresh logged-out active-use repro that shows the request path or GraphQL operation opened when the app.warp.dev socket appears?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that corrected repro shows logged-out idle Warp is silent, but entering active terminal use can open one idle app.warp.dev connection; this is best triaged as an offline-mode/network-control enhancement with documentation implications, pending endpoint confirmation..

Triage summary

The reporter's follow-up corrects the original claim: a fresh logged-out idle launch produced no external connections for about seven minutes, and the previously observed two sockets were residual from a prior logged-in session in the same process. The remaining reproducible case is narrower: after a cold logged-out launch and active terminal use, one low-traffic idle TLS connection to app.warp.dev appears.

This looks less like Warp Drive realtime sync and more like an unauthenticated app/backend request that starts once the client transitions into a terminal workspace. The strongest code-path candidate is the autoupdate/version-check flow: RootView starts autoupdate polling after reaching AuthOnboardingState::Terminal, AutoupdateState::start_polling immediately queues a poll, fetch_channel_versions calls ServerApi::fetch_channel_versions, and that hits /client_version on ChannelState::server_root_url() through the shared HTTP client. The HTTP client is configured for HTTP/2 idle keep-alive, so a completed request may leave one established idle TLS connection.

The privacy settings code confirms the current toggles are scoped controls rather than a global network kill switch: telemetry and crash-reporting gates prevent Rudder/Sentry traffic, AI settings gate AI surfaces, and warp_drive.enabled controls Warp Drive availability/UI rather than all client networking. The docs also currently say there is no explicit Offline Mode and that blocking app.warp.dev is treated as offline.

Suggested routing

• Treat this as an enhancement/documentation issue for a first-class offline/network-disable mode, or for clearer disclosure of which logged-out requests remain possible.
• Keep needs-info for one targeted capture that can identify the exact request behind the active-use socket.
• Related but not duplicate under the two-candidate threshold: warp_drive.enabled only hides the UI; Warp Drive's realtime connection stays open when disabled #15598 is specifically about the Warp Drive toggle not stopping a realtime connection while logged in/with prior state, and Warp maintains 4 persistent outbound HTTPS connections to Google Cloud and AWS without visible user disclosure #13894 is a broader Windows disclosure report about multiple persistent outbound connections.

Likely relevant files

• app/src/root_view.rs
• app/src/autoupdate/mod.rs
• app/src/autoupdate/channel_versions.rs
• app/src/server/server_api.rs
• crates/http_client/src/lib.rs
• app/src/auth/mod.rs
• app/src/drive/settings.rs
• app/src/auth/auth_view_shared_helpers.rs

Question reasoning

1. Can you attach a redacted Warp Network Log capture from a fresh logged-out active-use repro that shows the request path or GraphQL operation opened when the app.warp.dev socket appears? — The current evidence shows the destination and timing but not the specific endpoint; identifying the request would confirm whether this is the autoupdate/version-check path or another logged-out activity path.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz