From 528f84c7b3bd31995499644c95d4799b613209f3 Mon Sep 17 00:00:00 2001 From: finalerock44 Date: Mon, 9 Nov 2026 13:54:06 +0000 Subject: [PATCH] docs: sessions end after 30 days, or 7 days without use (dcd#2014) Console and `dcd login` sessions now have a maximum length and an inactivity timeout. Adds a Sessions section to the security overview, and replaces "you should rarely need to log in again" on the authentication and login pages with the limits. Also corrects the MCP server note: since CLI 5.6.0 the server refreshes a `dcd login` session while it runs, and picks up a new one after `dcd login` without a restart. It stops working when the session itself ends, so an API key is still the recommendation for servers that stay running. Hold until the limits are live on prod. --- cli/dcd-login.md | 2 +- getting-started/api-keys.md | 2 +- mcp/overview.md | 2 +- security/security-overview.md | 6 ++++++ 4 files changed, 9 insertions(+), 3 deletions(-) diff --git a/cli/dcd-login.md b/cli/dcd-login.md index 07b771b..dfc4100 100644 --- a/cli/dcd-login.md +++ b/cli/dcd-login.md @@ -82,4 +82,4 @@ The session from `dcd login` is written to: - `$XDG_CONFIG_HOME/dcd/config.json`, or - `~/.dcd/config.json` if `XDG_CONFIG_HOME` is not set -The file is created with `0600` permissions (owner read/write only) and holds your session tokens and the active team. When a command starts, the CLI refreshes the session if it's about to expire, so you should rarely need to log in again. A process that keeps running, such as the [MCP server](../mcp/overview.md), doesn't refresh its session, so use an API key for long-running processes. +The file is created with `0600` permissions (owner read/write only) and holds your session tokens and the active team. The CLI keeps the session fresh while you use it, but the session itself has a limit: it ends 30 days after you log in, or after 7 days without a `dcd` command, whichever comes first. When it ends, commands fail with a message telling you to run `dcd login` again. A process that keeps running, such as the [MCP server](../mcp/overview.md), stops working at the same point, so use an API key for long-running processes. See [Session limits](../security/security-overview.md#sessions). diff --git a/getting-started/api-keys.md b/getting-started/api-keys.md index 72f915f..1d20e55 100644 --- a/getting-started/api-keys.md +++ b/getting-started/api-keys.md @@ -16,7 +16,7 @@ This opens your browser, where you sign in (email OTP or Enterprise SSO) and aut - `$XDG_CONFIG_HOME/dcd/config.json`, or - `~/.dcd/config.json` if `XDG_CONFIG_HOME` is not set -The file is written with `0600` permissions (owner read/write only). When a command starts, the CLI refreshes the session if it's about to expire — you generally only log in again if you log out or switch machines. Long-running processes such as the [MCP server](../mcp/overview.md) don't refresh their session, so use an API key for those. +The file is written with `0600` permissions (owner read/write only). The CLI keeps the session fresh while you use it, but a session ends 30 days after you log in, or after 7 days without a `dcd` command, whichever comes first. Then the CLI tells you to run `dcd login` again. API keys don't expire this way, so use one for CI and for processes that keep running, such as the [MCP server](../mcp/overview.md). See [Session limits](../security/security-overview.md#sessions). ::: info No browser on the box (e.g. over SSH)? Run `dcd login --no-browser` and the CLI prints a URL to open elsewhere. diff --git a/mcp/overview.md b/mcp/overview.md index ff04ac8..9893ad5 100644 --- a/mcp/overview.md +++ b/mcp/overview.md @@ -44,7 +44,7 @@ When both are present, the environment variable wins. Credentials are resolved lazily on the first tool call, not at startup — so your client can connect and enumerate the tools before you've supplied a key, and a bad credential surfaces as a tool error rather than a server that won't start. ::: warning -The server resolves credentials once and reuses them for as long as it runs. A `dcd login` session is not refreshed after that, so a long-running server starts failing once the session expires, until you restart it. Use an API key for servers that stay running. +A `dcd login` session ends 30 days after you log in, or after 7 days without use. The server refreshes the session while it runs, but once the session ends, every tool call fails with a message telling you to run `dcd login` again. The server picks up the new session on the next call, without a restart. Use an API key for servers that stay running. ::: ## Tools diff --git a/security/security-overview.md b/security/security-overview.md index 3502b9e..4272fe5 100644 --- a/security/security-overview.md +++ b/security/security-overview.md @@ -26,6 +26,12 @@ Data held by our database and file storage providers is encrypted at rest with A On top of TLS, your uploads get envelope encryption by default. Before anything is uploaded, the CLI encrypts your app binary, flows and environment variables on your machine, each with its own random key (AES-256-GCM). It then encrypts each of those keys with DeviceCloud's public key (X25519), so the copies held in our storage and caches are ciphertext, and only our API can recover the keys that decrypt them. To turn envelope encryption off, pass `--no-encrypt` or set `DCD_ENCRYPT=0`. The upload is still encrypted in transit. +### Sessions + +Signing in to the console, or with `dcd login`, starts a session. A session ends 30 days after you sign in, or after 7 days without use, whichever comes first, and you then sign in again. An open console tab counts as use. The limits are checked when the session renews, which happens about once an hour, so a session can last up to an hour past them. + +You can see your sessions in the console under **Settings → Account → Active sessions**, sign out a single device, or sign out of all devices at once. API keys are not sessions, so these limits don't apply to them. + ### Data Retention Uploads (both binaries and workflow files) are automatically deleted 1 month after last use; result data including maestro logs, screenshots, videos and the environment variables passed with `--env` are retained for 6 months. Our database backups are kept for at most 6 months, so a backup copy of this data is gone at most 6 months after it is deleted.