[Feature]: Per-project environment variables

[yinheli]

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.

[viraptor]

This is something with another use case - for people using nixpkgs or similar type of management for dependencies, having replaced environment variables is critical, because the PATH may be entirely different for different projects.
Jetbrains family of IDEs has this issue too with people constantly asking for different env between projects.

I'm not sure direnv is that bad of an idea though - ensure it's activated for each spawned agent and it could be a simple way to punt the rest of the decisions onto the dev. I'd be happy with that solution.

[yinheli]

Hi @juliusmarminge — any chance this is on the roadmap?

README says contributions aren't accepted yet, but if you'd take a PR I'm happy to do it. Scope I had in mind: project-level env map, merged into provider subprocess on spawn, simple KV editor in project settings.

Let me know either way 👍

[bzbetty]

as an extension to this I think chat session based env variables could be handy for those of us using OTEL for tracking (eg to set OTEL_RESOURCE_ATTRIBUTES https://code.claude.com/docs/en/monitoring-usage)

[michft]

You are not there yet but if you want to crack enterprise, you will need "team" based otel tracking. (if for no other reason to track budget and spend)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Issue #523 adds automatic project environment activation as a distinct requirement for this proposal.

The provider process should resolve the target project or worktree directory and activate its environment for every spawn. Changing cwd alone is insufficient for direnv. The resulting PATH and tool variables must reach the provider and its commands. The reported case uses direnv with flake.nix, with sgiath/nostr as an example project. Comments confirm Nix and mise cases. In particular, the mise report says an agent sometimes forgets the manual mise x -- wrapper. The original report names asdf as another manager that could be affected, but it does not include an asdf reproduction. Agent instructions are a workaround, not automatic activation.

Static project key-value variables and shell or environment-manager activation are separate implementation options. The first merges known values. The second evaluates the project environment on each provider spawn. Please keep both visible in this discussion rather than treating the static editor as full coverage of the activation request.

[sebastianpetrovski]

I have a working Codex-specific workaround for the automatic activation part of this proposal on NixOS, using T3 Code 0.0.40 and Codex 0.154.0.

I added a second native Codex provider whose binaryPath points to this wrapper instead of directly to codex:

#!/usr/bin/env bash
set -euo pipefail

# Avoid routine direnv status output on the provider stderr channel.
export DIRENV_LOG_FORMAT=
exec direnv exec "$PWD" /absolute/path/to/codex "$@"

The provider is displayed as Codex (direnv), while the ordinary Codex instance remains available as a fallback. T3 starts the provider binary with the selected project/worktree as its cwd and appends its normal app-server arguments, so this wraps the whole Codex app-server process rather than asking the model to remember nix develop -c for individual shell commands. In practical project sessions, Codex now sees the Node/pnpm/tool environment supplied by the project .envrc.

A few important behavior details:

• The wrapper never runs direnv allow; trust remains an explicit user decision.
• No .envrc gives the normal baseline environment.
• An allowed .envrc (including use flake) supplies the provider environment.
• An unapproved or broken .envrc prevents that provider from starting rather than silently falling back.
• With direnv 2.37.1, an explicitly denied file is skipped and Codex starts with the baseline environment, following direnv’s own semantics.
• Worktree approvals are path-specific, and an existing provider process must be restarted after changing .envrc, flake.nix, or flake.lock.
• Variables and secrets exported by .envrc enter Codex and its descendants, so they must be handled accordingly.

This is useful implementation evidence and a viable local workaround, but it is not a complete solution for this discussion: it is Codex-specific, does not activate T3 terminals/previews/helpers or other providers, and does not implement the separate static project-variable UI requested here. A general upstream design would ideally resolve and activate the target project/worktree environment for every provider spawn, independent of the agent remembering wrapper commands.