Direnv is another tool that does this.

Direnv is another tool that does this.

Seconded. I'd favor a portable solution over something specific to my terminal (emulator) any day.

@reitzig direnv, is a shell tool. by portable do you mean across OSs or across shells, ...? The plan is to build Warp for Mac, web (wasm), linux, and windows.

Portable across terminals; my colleagues might not use Warp even if I did and agreeing on a "background" tool is a lot easier than a "frontend" tool.

"Hi, I'm using asdf (https://github.com/asdf-vm/asdf) a lot as a tool to manage different versions of for instance Golang/Elixir/Erlang/Scala. which I guess uses shims to link certain versions to certain directories. but it doesn't work at all in Warp, not sure if this is a warp issue or an asdf one though"

https://github.com/asdf-community/asdf-direnv

From @rkabrick via Discord:
https://discord.com/channels/851854972600451112/906269689116770304/909449811428786196

3.) Someone had mentioned environment variable management and while I think that has merit to an extent, I feel as though this could be extended much further. I believe that integrating some notion of project management into Warp would be dope. Idk if you are familiar with modulefiles or modules but they are effectively a way for sys-admins to provide and isolate different environment variables & software packages such that users can choose to load and unload things like cmake/3.18.2 or clang/12.1.0. I use them personally for any projects that use languages without virtual environment features (C, C++, etc.). I think the sky is the limit as far as potential project management integration to Warp. Setting environment variables based on the current project, having history files specific to projects, having directories that are easy to navigate to based on the project, and maybe even some type of git integration for every changed file, command issued, etc. Also having a build keyword that can be issued anywhere so long as a project is activated that will commence the build command for a given project

I would probably choose 1password plugin for warp, instead of warp offering me their custom stuff. Why? I dont want a terminal managing my secret. :P

The project-level stuff is quite cool (deserves a separate thread maybe?), but it I dislike the environment idea, especially because it feels pretty one-dimensional. Imagine projects with multiple environment requirements for development (a la profiles). You would then need a way to discern between them at Warp level (or you'd ignore the profiles, which is what always happens and everyone's wallowing in a sad half-solution).

Also, depending on how this is implemented (from a workflow level), you can have an increasingly divergent workflow between yourself and colleagues, etc. This is something others have already expressed concerns with.

What might be cool instead is having a way to better integrate with the shell and the environment/tooling... Someone mentioned direnv earlier. An example of this could be to respond to the value within the environment. Eg, if USER is root, then allow an override to tint the background and change the prompt. Making this generic and customisable is obviously much harder to design without having it feel clunky, though.

Basically, the whole of my post can be summarised as "augment what's there, don't replace it", which feels like what Warp has done so far. I mostly because replacing what's there in this case comes with an unimaginable scope creep, and then suddenly they become an all-or-nothing thing, mixed in with the sunk-cost fallacy, this becomes a great recipe for half-baked cult features (by cult features I mean something like a "cult fan"; it's absolutely adored by a small niche, but much less useful in the "real world")

Node versioning NVS support

Shared/managed secrets in a terminal context is a genuinely useful feature — the current pain is that secrets live in .env files or system keychain in ways that are hard to share safely with a team.

A few patterns for the current state:

1. direnv + external secret backend (most team-friendly):

# .envrc (committed to repo, no secrets)
export DATABASE_URL=$(op read "op://Engineering/Postgres/url") # 1Password CLI
export API_KEY=$(aws ssm get-parameter --name "/myapp/api-key" --query "Parameter.Value" --output text)

2. Shared .env.vault pattern (à la dotenv-vault):

# .env.vault is encrypted, safe to commit
# DOTENV_KEY stays in team secrets manager
dotenv-vault push
dotenv-vault pull # team member pulls their copy

3. For the Warp team specifically — integrations that would unlock this:

The most powerful version would be:

• Warp manages a "workspace secret store" (backed by your choice: 1Password, AWS Secrets Manager, Vault)
• When you open a terminal session in a project dir, Warp auto-injects the relevant secrets as env vars (similar to how direnv works but at the Warp layer)
• Sharing a "project config" with a teammate propagates which secrets they need to fetch

The hard part is secret lifecycle: secrets rotate, people leave teams, etc. A revocation model needs to be part of the design.

Warp's real-time collaboration angle makes this even more interesting — shared sessions where secrets are visible to some participants and masked from others (screen share safe mode)?