Runtime environment variables

workflow code uniformly reads the configuration via workflow.getEnv(name). Do not rely directly on a platform-specific configuration reading method.

const apiKey = workflow.getEnv("EXAMPLE_API_KEY");

Source order

Different sources of values for different run locations:

Operating position	Configuration Source
Terminal/ CLI	workflow directory .env, and then process env.
Desktop	The environment variable configuration saved by the local project.
Workflow Server	workflow environment variable configuration saved on the server side.

The server also loads server/.env and the project root directory .env when it starts. Environment variables that already exist in the shell take precedence, and .env only adds missing items.

Desktop Local Environment Variables

The Desktop Environment action manages local-run variables. Once saved, the next local run reads them in executor context. Desktop-local variables are not saved to a Server draft automatically and do not affect a published version.

Server environment variable

The Environment Variables page of Server Web manages the configuration used by remote runs. Server run, external API, Embed, and Webhook all read server-side variables. Key class variables should only be written to the server configuration and should not appear in public pages, logs, or document examples.

LLM Provider environment variable

workflow.createLLMProviderFromEnv() Default Read:

• LLM_TYPE
• LLM_API_KEY
• LLM_BASE_URL
• LLM_MODEL

These variables also enter the provider via workflow.getEnv.

The Conversation, Codex, and OpenCode built-in projects do not read these provider environment variables, but instead use the system AI configuration of the currently logged-in account. OpenCode also does not read OPENCODE_PROVIDER_*, user global OpenCode configuration, or opencode auth login state.

Third-party service invocation

For third-party calls other than LLM, it is recommended to directly use fetch or the business SDK in workflow and read the key through workflow.getEnv:

const response = await fetch("https://api.example.com/run", {
  method: "POST",
  headers: {
    "content-type": "application/json",
    authorization: `Bearer ${workflow.getEnv("EXAMPLE_API_KEY") ?? ""}`,
  },
  body: JSON.stringify({ input }),
});

Example workflow

Example workflow can declare its own SDK as a project dependency and read credentials through environment variables:

Example	Common Variables	Description
openai-agents	OPENAI_API_KEY, OPENAI_BASE_URL	Calls the OpenAI Agents SDK to demonstrate local tools.
claude-agent	ANTHROPIC_API_KEY	Call the Claude Agent SDK and reuse the session as conversation.
pi-agent	ANTHROPIC_*, OPENAI_*	Switches provider through Advanced options and uses the project knowledge-base tool.
opencode	No provider environment variable	Select Provider and Model from the system AI configuration of the currently logged-in account.
gpt-image	OPENAI_API_KEY, OPENAI_BASE_URL	Calls image generation and displays the result as an output item.

The local terminal can put variables in the example directory .env;Desktop and server run are injected from their own saved workflow environment variables. Examples that require real external services should provide dry-run or opt-in smoke to avoid default tests relying on remote platforms.