direnv / flake.nix environment is not propagated to agent sessions

I’m using direnv together with flake.nix to provide project-local dependencies automatically when entering a directory.

This setup works as expected in:

terminal-based agents
Cursor
Zed

But when I run t3code, the agent behaves as if those dependencies are not available in the project environment.

For example, tools/binaries made available through direnv are visible in my shell, but the T3 Code agent reports that they are missing:

Expected behavior

T3 Code should use the environment for the target project/worktree directory
if a project relies on direnv + flake.nix, the agent should see the same dependencies that are available in a normal shell inside that directory

Actual behavior

T3 Code appears to inherit only the parent process environment
workspace-local environment activation does not seem to happen for the agent session

Notes

My guess is that this may also affect other environment managers with similar behavior, such as asdf, mise, nix develop, etc.
I suspect the issue is that changing cwd alone is not enough; tools like direnv require explicit environment activation for that directory

Example project

Here is one of my projects that uses this setup: https://github.com/sgiath/nostr

+1 on this. I have exactly this use case as well

@Eriyc

@Eriyc I have added this to my global Codex AGENTS.md and it mostly solved any problems with this kind of setup:

## NixOS

This is a NixOS system. Many projects use `flake.nix`; when project-specific tools are missing, prefer `nix develop -c <command>`. If `direnv` has already loaded the dev shell, run commands normally.

@Eriyc I have added this to my global Codex AGENTS.md and it mostly solved any problems with this kind of setup:

NixOS

This is a NixOS system. Many projects use flake.nix; when project-specific tools are missing, prefer nix develop -c <command>. If direnv has already loaded the dev shell, run commands normally.

If unrelated to NixOS, this has worked for me on all my projects:

we use nix devshell, run all commands inside it with nix develop -c <commands>

The overhead of running a nix dev command if direnev is aldready loaded, is not that bad in most cases

I have this very same problem.
Really want to make the most out of T3 code, but it is currently too limited to compete even with Antrophic claude desktop.
Antrophic at least has the cloud infrastructure to let you work on things while you are away, despite it doesn't play nice with local envs either.
But T3 has none of that.
I still have faith that the team will consider this and fix it. I don't have any faith in atrophic for such feature (they're too dumb for considering this), but I do trust the T3 team!

I have this very same problem. Really want to make the most out of T3 code, but it is currently too limited to compete even with Antrophic claude desktop. Antrophic at least has the cloud infrastructure to let you work on things while you are away, despite it doesn't play nice with local envs either. But T3 has none of that. I still have faith that the team will consider this and fix it. I don't have any faith in atrophic for such feature (they're too dumb for considering this), but I do trust the T3 team!

I guess the issue is becuase the subshells used are not login-shells, but guiding models to use nix develop -c <command> have worked flawlessly for me :)

I guess the issue is becuase the subshells used are not login-shells, but guiding models to use nix develop -c <command> have worked flawlessly for me :)

Yes, that is indeed the problem. I'm trying to workaround it with more "traditional" approaches.
How do you set such thing "globally" and make sure it is only used when needed ?
Some of my project has a parent folder with the flake.nix, so it is not obvious in which projects it needs to be used

use bash -l

from man pages:

man bash
...
 -l        Make bash act as if it had been invoked as a login shell (see INVOCATION below).

but again, just making agents use nix develop -c <command> solves the whole thing. In my experience the overhead of loading direnv for any command is substantial compared to executing the nix develop.

Ditto for mise. I've instructed my agent to use mise x -- [COMMAND] but it occasionally forgets and has to redo a command. I'd rather it not have to think about that; reserve its attention for more important things.

If you're content with using a hacky vibe-coded patch, use this: t3code.patch

To use with nixpkgs: t3code-nixpkgs.patch:

{
  inputs = {
    nixpkgs.url = "...";
  };

  outputs =
    inputs:

    let
      nixpkgs = inputs.nixpkgs.legacyPackages."x86_64-linux".applyPatches {
        name = "nixpkgs-patched";
        src = inputs.nixpkgs;
        patches = [
          ./patches/t3code-nixpkgs.patch
        ];
      };
    in
    {
      nixosConfigurations = {
        desktop = nixosSystem {
          system = "x86_64-linux";
          specialArgs = { inherit inputs; };
          modules = [ ./hosts/desktop/configuration.nix ];
        };
      };
    };
}

patch was generated with GPT-5.6 Sol with Medium thinking level on OpenCode.

If you're content with using a hacky vibe-coded patch, use this: t3code.patch

To use with nixpkgs: t3code-nixpkgs.patch:

{
inputs = {
nixpkgs.url = "...";
};

outputs =
inputs:
let
  nixpkgs = inputs.nixpkgs.legacyPackages."x86_64-linux".applyPatches {
    name = "nixpkgs-patched";
    src = inputs.nixpkgs;
    patches = [
      ./patches/t3code-nixpkgs.patch
    ];
  };
in
{
  nixosConfigurations = {
    desktop = nixosSystem {
      system = "x86_64-linux";
      specialArgs = { inherit inputs; };
      modules = [ ./hosts/desktop/configuration.nix ];
    };
  };
};
}
patch was generated with GPT-5.6 Sol with Medium thinking level on OpenCode.

Tell sol to make it cross-architecture compatible using forAllSystems helper or something like that

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Thanks for the detailed report. We are tracking per-project provider environments in Ideas discussion #6715.

Automatic activation for a target project or worktree is new provider-process behavior. It is related to the discussion's static project environment variables, but it is not the same implementation. I added the separate activation scope before closing this issue: run it for every provider spawn, propagate project-specific PATH and tool variables, support Nix and similar managers such as mise and asdf, and do not depend on an agent remembering a wrapper command.

I'm closing this as a feature request tracked in Ideas as part of an automated pass on all open issues. This does not mean automatic project environment activation is implemented. The original report, comments, workaround notes, and example project remain available here.

Navigation Menu

Repository navigation

`direnv` / `flake.nix` environment is not propagated to agent sessions #523

Expected behavior

Actual behavior

Notes

Example project

NixOS

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

direnv / flake.nix environment is not propagated to agent sessions #523

Description

Expected behavior

Actual behavior

Notes

Example project

Activity

Eriyc commented on Mar 14, 2026

sgiath commented on Mar 21, 2026

jakob1379 commented on Mar 23, 2026

NixOS

danielo515 commented on Apr 10, 2026

jakob1379 commented on Apr 10, 2026

danielo515 commented on Apr 10, 2026

jakob1379 commented on Apr 10, 2026

sargunv commented on Apr 12, 2026

pompydev commented on Jul 22, 2026

danielo515 commented on Jul 22, 2026

t3dotgg commented on Aug 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`direnv` / `flake.nix` environment is not propagated to agent sessions #523