[Feature]: Per-project environment variables #1703

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

All provider sessions (Codex and Claude) inherit the same process.env from the T3 Code server process. When working with multiple projects, there's no way to use different API keys, endpoints, or provider-specific environment variables per project.

This is a common need for developers who work across multiple accounts, clients, or API providers within a single T3 Code instance.

Proposed solution

Allow users to define environment variables at the project level. These variables would be merged into the child process environment when spawning provider sessions for that project, with project-level values taking precedence over the server's inherited environment.

A simple key-value editor in the project settings UI would be sufficient.

Why this matters

Unlocks multi-account and multi-provider workflows without requiring users to restart T3 Code with different environment variables each time they switch projects.

Smallest useful scope

Store a key-value map of environment variables per project and merge them into the provider subprocess environment at spawn time. No .env file import, templating, or encryption needed initially.

Alternatives considered

• Running separate T3 Code instances per project — functional but wasteful.
• Using direnv or shell profiles — only affects the initial server startup, not runtime project switching.

Risks or tradeoffs

• Secrets stored without encryption at rest, consistent with current settings storage. Encryption could be a follow-up.
• Project-level vars could unintentionally override system-critical variables (e.g., PATH). A denylist may be worth considering.

Examples or references

No response

Contribution

• I would be open to helping implement this.