Support dynamic env variables, e.g. from project-local `direnv`

[jinnovation]

Currently, agent-shell supports "plain" .env files, as documented here.

My team's use cases revolve heavily around direnv, which allows for some "Bash-like" initialization of env variables. Case in point, from direnv docs:

[The .direnv file] is loaded into a bash sub-shell and all exported variables are then captured by direnv and then made available to the current shell.

This is important for e.g. re-authenticating against cloud environments and setting env variables based on the success/failure of that re-authentication flow.

Proposed user flow:

• On initialization, agent-shell looks to see if there is a .direnv file in the project's root directory;
• If found, attempt to execute it;
• If execution fails, allow user to configure agent-shell to either start up anyway or fail immediately and refuse to start up;
• If execution succeeds, all exported env variables are exposed to agent-shell for use.

Checklist

• I've read the README's Issues section.
• I'm running the latest agent-shell version.
• I'm running the latest agent version (ie. Claude Code, Geminig CLI).
• I'm running the latest agent ACP package (ie. claude-code-acp).
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package.
• For issues, I'm including ACP traffic (as per README).

[xenodium]

I think this is probably already supported if you're using something like emacs-direnv? From their page:

It works by invoking direnv to obtain the environment for the current file, then updating the emacs variables process-environment and exec-path.

Since emacs-direnv is setting process-environment, using (agent-shell-make-environment-variables :inherit-env t) should do the job.

[jinnovation]

I think this is probably already supported if you're using something like emacs-direnv?

Good point. will give this a try and report back.

[jinnovation]

I suspect this requires some finagling to get things playing nicely with project-specific .envrc files, e.g. that the Emacs instance itself wasn't initialized "under" (and that therefore wouldn't have been caught with the one-off agent-shell-make-environment-variables invocation in init.el). Will investigate further. Happy to contribute a docs PR w/ whatever I find.

[jinnovation]

okay, figured it out. to get agent-shell working with project-local direnv files, this works in tandem with emacs-direnv:

(defun jinnovation/agent-shell-direnv ()
  (interactive)
  (let ((agent-shell-anthropic-claude-environment (agent-shell-make-environment-variables
                                                   :inherit-env t)))
    (agent-shell)))

i'm happy to work with this for now as an interim personal solution :D that said, @xenodium, WDYT of building in mechanisms to more natively support dynamically-switching environment sets? something minimal that comes to mind: allow agent-shell-anthropic-claude-environment and its peers to be callables that produce string-lists in addition to static string-lists. this would allow users like myself to set something like the following to have M-x agent-shell reload the env on every invocation:

(setq agent-shell-claude-env (lambda () (agent-shell-make-env-vars :inherit-env t)))

happy to submit a PR for this if valuable.

[Rutherther]

Just a note that with envrc I did not really have to change anything and I get the expected behavior of agents having the desired environment from direnv.

[jinnovation]

Just a note that with envrc I did not really have to change anything and I get the expected behavior of agents having the desired environment from direnv.

looks like it for me as well! i'm guessing this is due to envrc.el setting process-environment directly buffer-locally in the agent-shell buffer, which allows the agent to pick the set variables up.

looks like my proposed changes might not be necessary then 👍 i'll happily submit a documentation PR in that case.

[xenodium]

i'll happily submit a documentation PR in that case.

@jinnovation SGTM. Thank you.