Support dynamic environments without restarting eca (i.e. inherit ENV from each chat's ENV)

[nico202]

To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.

Description

I use eca with eca-emacs inside virtual environments managed by guix/nix + direnv (envrc in Emacs). These environments have limited software (e.g., gcc might be missing) and custom environment variables.

Problems encountered

1. The environment depends on the first run of eca. If I start eca in an environment without gcc, then gcc is not available in other chats, even if those chats are opened later in environments that do have gcc.

2. No way to update the environment without killing all sessions. To change the environment, I have to kill all eca sessions and restart it in the correct environment.

Proposed solution

Send, alongside user messages, the current environment variables.
When the LLM invokes a shell, it should be executed with the environment provided by the user at the time of the message. The editor plugin should send the environment when configured to do so.

This should probably be opt-in, either via config or per session.

Questions for the community

• Are there security implications to consider?
• How are other users handling dynamic environments with eca?

[ericdallo]

@nico202 I believe this will give more context on how people are using eca sandboxed
I use nix too, but I don't think it's easy to fix this problem since everything is inherited from server env, also not sure it's a good idea to include all env as this might result in bigger costs, maybe a workaround for you is to have a rule or something in AGENTS.md saying "Run env to get your env vars before running commands".

c/c @zikajk in case has anything in mind

[nico202]

I might have expressed myself wrong. This kind of instrumentation should not be done by the llm, but by the eca server itself. Editor plugin sends ENV to eca server, eca server keeps it and uses it inside shells. The llm should never see the env it is in as it can exflitrate secrets

[ericdallo]

Ah I see, so what you are suggesting is: when server needs to spawn a bash command, instead of use the env from the server process itself, to use some other passed by the client during startup?
Interesting, I wonder, why the client env would have what you need but the server not if the server is spawned by client inheriting the client env

[nico202]

If I get correctly how Eca works right now, there only 1 server which manages multiple clients. So the server inherits the env from the first client only

update: also, the client env (in case of envrc at least) might change, and this change is not reflected in the spawned server

[zikajk]

I think that we shouldn't attach env variables to prompts (if you need it, you can already create a hook for that) but what we could do is to have something like $ECA_ENV_FILE (like CC has CLAUDE_ENV_FILE) that is dynamically added to every shell command and created when chat starts. The question is - should it be tied to the chat, to the workspace, should it be persisted?

(The nice thing is that hooks can use this variable and they can update the file. The worse part is that some users weren't happy that this file contains each env var they have on their system :-))

[ericdallo]

@nico202 right now eca is spawned by client for every workspace you have, so there is a server process by workspace by client, this is not a big deal as eca server is pretty fast and small.

[zikajk]

Btw. More info if you are interested https://code.claude.com/docs/en/env-vars

(Search for claude_env_file)