Summary

A user is frustrated that while Warp stores static environment variables securely at rest, there is no built-in way to securely use them programmatically (e.g., in automated skills or cloud agents) without either writing them to disk (like a .env file) or exposing them in the shell session's environment where they can be leaked by background processes.

Problem

The user wants to use an API key (e.g., for Monday.com) in an automated Warp skill without requiring a Touch ID prompt via 1Password. To achieve headless automation, the user must rely on a Service Account token or static variable, but doing so forces them to store or expose the token in plaintext (.env or shell profile), bypassing Warp's security benefits. The user feels it is a failure that Warp securely stores variables but lacks a secure execution model to call them dynamically in scripts without exposure.

Expected behavior

Warp should provide a way to inject secrets into scripts, workflows, or cloud agents dynamically at runtime without exposing them to the broader shell environment or requiring them to be written to disk in plaintext.

Actual behavior

To achieve automation without human interaction (no biometric prompt), users must currently expose secrets in plaintext files or global shell environment variables.

Reproduction steps or desired workflow

1. Attempt to run an automated Warp skill (or cloud agent) that requires an external API key (e.g., Monday.com).
2. To avoid biometric prompts (like 1Password Touch ID) in headless environments, attempt to use a 1Password Service Account token or a Warp Static Environment Variable.
3. Observe that these tokens must be stored in a .env file, shell profile, or globally exported variable to function automatically.
4. Conclude that the secret is now exposed in plaintext on disk or in the process environment, defeating the purpose of secure storage.

Warp version

Unknown

Operating system

macOS