[GH-ISSUE #973 ] Issue: exec: &#34;node&#34;: executable file not found in $PATH: unknown #570

Author

Owner

@catthehacker commented on GitHub (Jan 28, 2022):

container: is not yet supported (as in, it will run in a container, but you won't get node and other stuff that GHA mounts into that container for it to work properly)

@catthehacker commented on GitHub (Jan 28, 2022): `container:` is not yet supported (as in, it will run in a container, but you won't get `node` and other stuff that GHA mounts into that container for it to work properly)

kerem commented

Author

Owner

@grahamb commented on GitHub (Jan 28, 2022):

Well, that would explain it. Would you consider adding this limitation to the known issues section of the readme? It would have saved me a few frustrating hours yesterday.

@grahamb commented on GitHub (Jan 28, 2022): Well, that would explain it. Would you consider adding this limitation to the [known issues](https://github.com/nektos/act#known-issues) section of the readme? It would have saved me a few frustrating hours yesterday.

kerem commented

Author

Owner

@ZauberNerd commented on GitHub (Feb 1, 2022):

Duplicate of #917

@ZauberNerd commented on GitHub (Feb 1, 2022): Duplicate of #917

kerem commented

Author

Owner

@JJRcop commented on GitHub (Feb 24, 2022):

Is this closed because it's a duplicate or because it's fixed? I assume duplicate, but want to make sure.

@JJRcop commented on GitHub (Feb 24, 2022): Is this closed because it's a duplicate or because it's fixed? I assume duplicate, but want to make sure.

kerem commented

Author

Owner

@iTrooz commented on GitHub (Aug 19, 2023):

Duplicate of https://github.com/nektos/act/issues/917

Hello, I think #917 was not a duplicate (I'm not sure why it was considered as so, as #917 is about using docker as a step, and this issue is about putting node inside containers)

Could you reopen, and point it out in "known issues" ?

(I can still reproduce this as of 0.2.34 using the author's instructions)

@iTrooz commented on GitHub (Aug 19, 2023): > Duplicate of https://github.com/nektos/act/issues/917 Hello, I think #917 was not a duplicate (I'm not sure why it was considered as so, as #917 is about using docker as a step, and this issue is about putting node inside containers) Could you reopen, and point it out in "known issues" ? (I can still reproduce this as of 0.2.34 using the author's instructions)

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Aug 22, 2023):

Yeah this issue is unrelated to 917.

However changing this would be a lot of work and would reduce platform support to what GitHub supports so I would suggest to keep current behavior for platforms not supported by GitHub.

@ChristopherHX commented on GitHub (Aug 22, 2023): Yeah this issue is unrelated to 917. However changing this would be a lot of work and would reduce platform support to what GitHub supports so I would suggest to keep current behavior for platforms not supported by GitHub.

kerem commented

Author

Owner

@iTrooz commented on GitHub (Aug 22, 2023):

I don't understand, what are "platforms that github supports" ?

I thought I was able to use any container image I wanted, and github would somehow inject a nodejs runtime in it. Is that not the case, are popular container images manually patched by github's team ?

@iTrooz commented on GitHub (Aug 22, 2023): I don't understand, what are "platforms that github supports" ? I thought I was able to use any container image I wanted, and github would somehow inject a nodejs runtime in it. Is that not the case, are popular container images manually patched by github's team ?

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Aug 22, 2023):

I don't understand, what are "platforms that github supports" ?

linux x86_64, linux alpine x86_64 (container only), linux armv7, linux arm64, windows x86_64, windows arm64, macOS x86_64, macOS arm64

I thought I was able to use any container image I wanted

No, that's not the case. You cannot use i386 (node actions won't work, partially working), arm64 and armv7 containers on a x86_64 runner.

This works in act, by providing node in PATH

are popular container images manually patched by github's team ?

No, not patched.

act works also on freebsd, plan9, solaris, openbsd, dragonflybsd and on riscv, i386, ppc64, mips64...

point it out in "known issues" ?

I point that out in my downstream project github-act-runner under Known limitations, but not in act itself. I didn't introduce this in act.

@ChristopherHX commented on GitHub (Aug 22, 2023): > I don't understand, what are "platforms that github supports" ? - linux x86_64, linux alpine x86_64 (container only), linux armv7, linux arm64, windows x86_64, windows arm64, macOS x86_64, macOS arm64 > I thought I was able to use any container image I wanted No, that's not the case. You cannot use i386 (node actions won't work, partially working), arm64 and armv7 containers on a x86_64 runner. This works in act, by providing `node` in `PATH` > are popular container images manually patched by github's team ? No, not patched. act works also on freebsd, plan9, solaris, openbsd, dragonflybsd and on riscv, i386, ppc64, mips64... > point it out in "known issues" ? I point that out in my downstream project github-act-runner under Known limitations, but not in act itself. I didn't introduce this in act.

kerem commented

Author

Owner

@iTrooz commented on GitHub (Aug 22, 2023):

I'm not sure I understand why we are talking about architecture

This works in act, by providing node in PATH

How does github does that in container images ? And couldn't you also do that ?

@iTrooz commented on GitHub (Aug 22, 2023): I'm not sure I understand why we are talking about architecture > This works in act, by providing node in PATH How does github does that in container images ? And couldn't you also do that ?

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Aug 22, 2023):

How does github does that in container images ?

Each release comes with node binaries in an external tool folder, which it bind mounts into the container.

Then it uses the full path to external tools mount node tool.

And couldn't you also do that ?

Yes, I never said impossible. Only much work.

@ChristopherHX commented on GitHub (Aug 22, 2023): > How does github does that in container images ? Each release comes with node binaries in an external tool folder, which it bind mounts into the container. Then it uses the full path to external tools mount node tool. > And couldn't you also do that ? Yes, I never said impossible. Only much work.

kerem commented

Author

Owner

@NNNNzs commented on GitHub (Oct 9, 2023):

i have same problem，Have you solved it yet？

@NNNNzs commented on GitHub (Oct 9, 2023): i have same problem，Have you solved it yet？

kerem commented

Author

Owner

@dimaqq commented on GitHub (Nov 17, 2023):

I wonder if I'm hitting the same problem:

The 3rd party action.yaml has this code:

runs:
  using: 'node16'
  main: 'dist/setup/index.js'
  post: 'dist/cache-save/index.js'
  post-if: success()

Paths under dist seem OK.

Somehow, the main section succeeds, but the post section fails with:

[test.yaml/pytest-3]   🐳  docker exec cmd=[node /var/run/act/actions/actions-setup-python@v4/dist/cache-save/index.js] user= workdir=
| OCI runtime exec failed: exec failed: unable to start container process: exec: "node": executable file not found in $PATH: unknown

Real GHA: OK
act x84-64 host: I can't test
act ARM 64 host: Fail (I'm using act --container-architecture linux/amd64 and relying on Docker Desktop / Rosetta to run foreign arch)

@dimaqq commented on GitHub (Nov 17, 2023): I wonder if I'm hitting the same problem: The 3rd party action.yaml has this code: ``` runs: using: 'node16' main: 'dist/setup/index.js' post: 'dist/cache-save/index.js' post-if: success() ``` Paths under `dist` seem OK. Somehow, the `main` section succeeds, but the `post` section fails with: ``` [test.yaml/pytest-3] 🐳 docker exec cmd=[node /var/run/act/actions/actions-setup-python@v4/dist/cache-save/index.js] user= workdir= | OCI runtime exec failed: exec failed: unable to start container process: exec: "node": executable file not found in $PATH: unknown ``` Real GHA: OK `act` x84-64 host: I can't test `act` ARM 64 host: Fail (I'm using `act --container-architecture linux/amd64` and relying on Docker Desktop / Rosetta to run foreign arch)

kerem commented

Author

Owner

@dimaqq commented on GitHub (Nov 17, 2023):

I made a MRE for my flavour of this issue: https://github.com/dimaqq/mre-973

@dimaqq commented on GitHub (Nov 17, 2023): I made a MRE for my flavour of this issue: https://github.com/dimaqq/mre-973

kerem commented

Author

Owner

@shqear93 commented on GitHub (Jan 1, 2024):

I have the same issue here

@shqear93 commented on GitHub (Jan 1, 2024): I have the same issue here

kerem commented

Author

Owner

@billyjbryant commented on GitHub (Jan 2, 2024):

I'm experiencing this same issue no matter what source image I use, my own or the act provided images.

@billyjbryant commented on GitHub (Jan 2, 2024): I'm experiencing this same issue no matter what source image I use, my own or the act provided images.

kerem commented

Author

Owner

@virzak commented on GitHub (Jan 3, 2024):

Use this code to install node:

- name: "Determine prerequisites"
  id: prereq
  run: |
    echo "need_node=$(command -v node >/dev/null 2>&1 && echo 0 || echo 1)" >> $GITHUB_OUTPUT

# Consider switching to https://github.com/actions/setup-node when it works
# https://github.com/nektos/act/issues/973
- name: Install node
  if: ${{ steps.prereq.outputs.need_node == '1' }}
  run: |
    if [ "${RUNNER_OS,,}" = "windows" ]
    then
      choco install nodejs -y
      echo "C:\Program Files\nodejs" >> $GITHUB_PATH
    else
      curl -sS https://webi.sh/node | sh
      echo ~/.local/opt/node/bin >> $GITHUB_PATH
    fi

If you need yarn too, see this implementation.

@virzak commented on GitHub (Jan 3, 2024): Use this code to install node: ```yml - name: "Determine prerequisites" id: prereq run: | echo "need_node=$(command -v node >/dev/null 2>&1 && echo 0 || echo 1)" >> $GITHUB_OUTPUT # Consider switching to https://github.com/actions/setup-node when it works # https://github.com/nektos/act/issues/973 - name: Install node if: ${{ steps.prereq.outputs.need_node == '1' }} run: | if [ "${RUNNER_OS,,}" = "windows" ] then choco install nodejs -y echo "C:\Program Files\nodejs" >> $GITHUB_PATH else curl -sS https://webi.sh/node | sh echo ~/.local/opt/node/bin >> $GITHUB_PATH fi ``` If you need `yarn` too, see this [implementation](https://github.com/zompinc/efcore-extensions/blob/c538b2da95595d7316ee2a3d8d970eb5aa2c6ed0/.github/workflows/build.yml#L43-L72).

kerem commented

Author

Owner

@github-actions[bot] commented on GitHub (Jul 2, 2024):

Issue is stale and will be closed in 14 days unless there is new activity

@github-actions[bot] commented on GitHub (Jul 2, 2024): Issue is stale and will be closed in 14 days unless there is new activity

kerem commented

Author

Owner

@iTrooz commented on GitHub (Jul 2, 2024):

Issue is stale but still present/problematic

@iTrooz commented on GitHub (Jul 2, 2024): Issue is stale but still present/problematic

kerem commented

Author

Owner

@glimchb commented on GitHub (Jul 10, 2024):

The node binary is just not in PATH
If you add it to PATH , all works fine

@glimchb commented on GitHub (Jul 10, 2024): The node binary is just not in PATH If you add it to PATH , all works fine

kerem commented

Author

Owner

@iTrooz commented on GitHub (Jul 10, 2024):

Yes, but this mean modifying the workflow to manually install node just for act to work, which may not be wanted

@iTrooz commented on GitHub (Jul 10, 2024): Yes, but this mean modifying the workflow to manually install node just for `act` to work, which may not be wanted

kerem commented

Author

Owner

@glimchb commented on GitHub (Jul 10, 2024):

in my image node was already present, so this did a trick for me

+    - name: Hack container for local development
+      if: ${{ env.ACT }}
+      run: echo /home/runner/externals/node20/bin >> $GITHUB_PATH
+

which is - I agree, less then ideal, because we have to modify the workflow just for ACT...

this PR #1503

allows to set custom ENV in the docker image like this:

FROM blah...
ENV PATH "/mycustom:$PATH"

I'm looking now if we can use act --env or something like that to set this externally without modifying workflow or base image...

@glimchb commented on GitHub (Jul 10, 2024): in my image node was already present, so this did a trick for me ``` + - name: Hack container for local development + if: ${{ env.ACT }} + run: echo /home/runner/externals/node20/bin >> $GITHUB_PATH + ``` which is - I agree, less then ideal, because we have to modify the workflow just for ACT... this PR #1503 allows to set custom ENV in the docker image like this: ``` FROM blah... ENV PATH "/mycustom:$PATH" ``` I'm looking now if we can use `act --env` or something like that to set this externally without modifying workflow or base image...

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Jul 10, 2024):

Caution

Loading node from PATH within a job and allowing it to be changed by setup-node is causing bugs and I plan to remove it #2372

in my image node was already present, so this did a trick for me
+    - name: Hack container for local development
+      if: ${{ env.ACT }}
+      run: echo /home/runner/externals/node20/bin >> $GITHUB_PATH
+
which is - I agree, less then ideal, because we have to modify the workflow just for ACT...

Tip

Specified in a Dockerfile keeps beeing working for now, until node is downloaded by act iff that ever happens

@ChristopherHX commented on GitHub (Jul 10, 2024): > [!CAUTION] > Loading node from PATH within a job and allowing it to be changed by setup-node is causing bugs and I plan to remove it #2372 > in my image node was already present, so this did a trick for me > > ``` > + - name: Hack container for local development > + if: ${{ env.ACT }} > + run: echo /home/runner/externals/node20/bin >> $GITHUB_PATH > + > ``` > > which is - I agree, less then ideal, because we have to modify the workflow just for ACT... > [!TIP] > Specified in a Dockerfile keeps beeing working for now, until node is downloaded by act iff that ever happens

kerem commented

Author

Owner

@glimchb commented on GitHub (Jul 10, 2024):

@ChristopherHX so is this a recommended workaround for now ?

FROM blah...
ENV PATH "/home/runner/externals/node20/bin:$PATH"

just making sure...

@glimchb commented on GitHub (Jul 10, 2024): @ChristopherHX so is this a recommended workaround for now ? ``` FROM blah... ENV PATH "/home/runner/externals/node20/bin:$PATH" ``` just making sure...

kerem commented

Author

Owner

@techanfa commented on GitHub (Nov 5, 2024):

+1, this basically makes it impossible to use any action/XXX without having a container that has node installed, and as many people mentioned, it feels like an anti-pattern to change your workflow so that it works locally when it already works on the hosted github runner.

@techanfa commented on GitHub (Nov 5, 2024): +1, this basically makes it impossible to use any action/XXX without having a container that has node installed, and as many people mentioned, it feels like an anti-pattern to change your workflow so that it works locally when it already works on the hosted github runner.

kerem commented

Author

Owner

@glimchb commented on GitHub (Nov 5, 2024):

we found this workaround eventually to avoid changing the code:

docker pull my-actions-runner-image:latest
RUNNER_PATH="$(docker image inspect my-actions-runner-image:latest  | jq -r '.[].Config.Env | map(select(startswith("PATH="))) | .[0]' | cut -d= -f2)"

gh act \
    --env "PATH=/home/runner/externals/node20/bin:$RUNNER_PATH" \
...

@glimchb commented on GitHub (Nov 5, 2024): we found this workaround eventually to avoid changing the code: ``` docker pull my-actions-runner-image:latest RUNNER_PATH="$(docker image inspect my-actions-runner-image:latest | jq -r '.[].Config.Env | map(select(startswith("PATH="))) | .[0]' | cut -d= -f2)" gh act \ --env "PATH=/home/runner/externals/node20/bin:$RUNNER_PATH" \ ... ```

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Nov 5, 2024):

development of act is running on a low flame, imho community code reviewers needed added as members.

Imagine throttled development due to code review requirement set up by the inactive owner.

/home/runner/externals/node20/bin is not part of every docker image.

You can run actions/runner locally like act as of 2021 just google runner.client, it's only a question of tooling

@ChristopherHX commented on GitHub (Nov 5, 2024): development of act is running on a low flame, imho community code reviewers needed added as members. Imagine throttled development due to code review requirement set up by the inactive owner. /home/runner/externals/node20/bin is not part of every docker image. You can run actions/runner locally like act as of 2021 just google runner.client, it's only a question of tooling

kerem commented

Author

Owner

@kaiserkiwi commented on GitHub (Mar 5, 2025):

I read this thread but I still don't really know how to solve this.
My .actrc looks like this

--container-architecture=linux/amd64
--container-daemon-socket -

And the step that fails in my Workflow-File looks like this:

- name: Setup Node
  uses: actions/setup-node@v3
  with:
    node-version: 20

The relevant part in the Terminal output is the following:

[Laravel/Pest tests] ⭐ Run Main Setup Node
[Laravel/Pest tests]   🐳  docker cp src=/Users/mkr/.cache/act/actions-setup-node@v3/ dst=/var/run/act/actions/actions-setup-node@v3/
[Laravel/Pest tests]   🐳  docker exec cmd=[node /var/run/act/actions/actions-setup-node@v3/dist/setup/index.js] user= workdir=
| OCI runtime exec failed: exec failed: unable to start container process: exec: "node": executable file not found in $PATH: unknown
[Laravel/Pest tests]   ❌  Failure - Main Setup Node

Is there any solution to get this running without modifing the Workflow file just to make it run with act? I have dozens of projects with dozens of workflows in many of them, so this would be pretty annoying and hard to sell for my team at work.

@kaiserkiwi commented on GitHub (Mar 5, 2025): I read this thread but I still don't really know how to solve this. My `.actrc` looks like this ``` --container-architecture=linux/amd64 --container-daemon-socket - ``` And the step that fails in my Workflow-File looks like this: ```yml - name: Setup Node uses: actions/setup-node@v3 with: node-version: 20 ```` The relevant part in the Terminal output is the following: ``` [Laravel/Pest tests] ⭐ Run Main Setup Node [Laravel/Pest tests] 🐳 docker cp src=/Users/mkr/.cache/act/actions-setup-node@v3/ dst=/var/run/act/actions/actions-setup-node@v3/ [Laravel/Pest tests] 🐳 docker exec cmd=[node /var/run/act/actions/actions-setup-node@v3/dist/setup/index.js] user= workdir= | OCI runtime exec failed: exec failed: unable to start container process: exec: "node": executable file not found in $PATH: unknown [Laravel/Pest tests] ❌ Failure - Main Setup Node ``` Is there any solution to get this running without modifing the Workflow file just to make it run with act? I have dozens of projects with dozens of workflows in many of them, so this would be pretty annoying and hard to sell for my team at work.

kerem commented

Author

Owner

@ahuret commented on GitHub (Mar 11, 2025):

@kaiserkiwi to resolve it add a step to install node in your container. For example if your container is some fedora image, add a step

    container:
      image: fedora:latest
    steps:
      - name: Install node to Fedora (workaround for act)
        run: dnf install -y nodejs

Issue is about act that doesn't mount some programs (as node) in the custom image container as GHA does, so to resolve it just need to install it in this custom image container by yourself. Indeed, it will make the workflow different when it runs with act vs GHA but it's workaround for act to work in that container: context.

@ahuret commented on GitHub (Mar 11, 2025): @kaiserkiwi to resolve it add a step to install node in your container. For example if your container is some fedora image, add a step ```yaml container: image: fedora:latest steps: - name: Install node to Fedora (workaround for act) run: dnf install -y nodejs ``` Issue is about `act` that doesn't mount some programs (as node) in the custom image container as GHA does, so to resolve it just need to install it in this custom image container by yourself. Indeed, it will make the workflow different when it runs with act vs GHA but it's workaround for act to work in that `container:` context.

kerem commented

Author

Owner

@joshunrau commented on GitHub (Apr 14, 2025):

steps:
  - name: Act Workaround # https://github.com/nektos/act/issues/973
    if: ${{ env.ACT }}
    run: curl -fsSL https://deb.nodesource.com/setup_22.x | bash && apt install -y nodejs

@joshunrau commented on GitHub (Apr 14, 2025): ```yaml steps: - name: Act Workaround # https://github.com/nektos/act/issues/973 if: ${{ env.ACT }} run: curl -fsSL https://deb.nodesource.com/setup_22.x | bash && apt install -y nodejs ```

kerem commented

Author

Owner

@bnthn commented on GitHub (May 6, 2025):

In my case the runs-on image broke while updating my Gitea Act Runner docker image from 2.5 to 2.11. I received the error running pipelines on catthehacker/ubuntu:act-latest, which was weird, since i hadn't touched that image. Apparently there can be inconsistencies of some kind that remove node from the container completely.

After removing the image from the build machine with docker rmi catthehacker/ubuntu:act-latest and let the Act Runner pull it again everything works fine again.

@bnthn commented on GitHub (May 6, 2025): In my case the `runs-on` image broke while updating my Gitea Act Runner docker image from 2.5 to 2.11. I received the error running pipelines on **catthehacker/ubuntu:act-latest**, which was weird, since i hadn't touched that image. Apparently there can be [inconsistencies](https://github.com/nektos/act/discussions/2628) of some kind that remove node from the container completely. After removing the image from the build machine with `docker rmi catthehacker/ubuntu:act-latest` and let the Act Runner pull it again everything works fine again.

kerem commented

Author

Owner

@marco-brandizi commented on GitHub (Aug 4, 2025):

I am on a Mac/ARM, I was getting this error with --container-architecture linux/amd64, which is suggested by act itself. The error went away when I started omitting this option and letting it to use the ARM architecture.

@marco-brandizi commented on GitHub (Aug 4, 2025): I am on a Mac/ARM, I was getting this error with `--container-architecture linux/amd64`, which is suggested by act itself. The error went away when I started omitting this option and letting it to use the ARM architecture.

kerem commented

Author

Owner

@CasparNuel commented on GitHub (Oct 29, 2025):

@ChristopherHX Has any progress been made on this issue?

Running jobs on containers that are tool-specific is a major pain currently.
Some jobs simply need to run in a container that only provides a very minimal set of tools (and do not provide a node executable).

This makes it so that actions like actions/checkout@v4 or actions/upload-artifact@v4 can never work in such scenarios. The only possible option would be to recreate the container using an environment that does provide a node executable, or to install the node executable in the container (this isn't always possible at all). This creates major overhead for jobs that run on specific containers that cannot provide node .

IMO, support for injecting node (and other required tools) into jobs running in a container is truly a requirement for act.

Since this issue was created in 2022 I hope there is a plan to implement this at some point? This really is a core feature for runners.

@CasparNuel commented on GitHub (Oct 29, 2025): @ChristopherHX Has any progress been made on this issue? Running jobs on containers that are tool-specific is a major pain currently. Some jobs simply _need_ to run in a container that only provides a very minimal set of tools (and do not provide a `node` executable). This makes it so that actions like `actions/checkout@v4` or ` actions/upload-artifact@v4` can never work in such scenarios. The only possible option would be to recreate the container using an environment that _does_ provide a `node` executable, or to install the ` node` executable in the container (this isn't always possible at all). This creates major overhead for jobs that run on specific containers that cannot provide `node` . IMO, support for injecting `node` (and other required tools) into jobs running in a `container` is truly a requirement for `act`. Since this issue was created in 2022 I hope there is a plan to implement this at some point? This really is a core feature for runners.

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Oct 29, 2025):

No maintainer can work on nektos/act right now, only owner cplee can. A merge helper GitHub Application insists on config updates that requires an admin to apply the changes.

I did a full stop at writing PRs to nektos/act due to this.

IMO, support for injecting node (and other required tools) into jobs running in a container is truly a requirement for act

I have written a program that does something like that implicitly in 2021, by letting you execute https://github.com/actions/runner locally with a local workflow definition file similar, but totally different implemented than act.

Has any progress been made on this issue?

No

I fear that the future of the nektos/act repository is unknown.

See my profile for a link to my current hard fork of act.

Due me me working on the gitea project as of recently, my plan is to turn into an mirror like repository hosted in the future on gitea.com.

@ChristopherHX commented on GitHub (Oct 29, 2025): No maintainer can work on nektos/act right now, only owner cplee can. A merge helper GitHub Application insists on config updates that requires an admin to apply the changes. I did a full stop at writing PRs to nektos/act due to this. > IMO, support for injecting `node` (and other required tools) into jobs running in a `container` is truly a requirement for `act` I have written a program that does something like that implicitly in 2021, by letting you execute <https://github.com/actions/runner> locally with a local workflow definition file similar, but totally different implemented than act. --- > Has any progress been made on this issue? No I fear that the future of the nektos/act repository is unknown. See my profile for a link to my current **hard fork** of act. Due me me working on the gitea project as of recently, my plan is to turn into an mirror like repository hosted in the future on gitea.com.

kerem commented

Author

Owner

@electrofelix commented on GitHub (Jan 29, 2026):

Looks like part of the underlying problem is that the default PATH environment differs between the default runner images and what is observed with GitHub hosted runners.

Extending the current medium image to have a separate user I noticed that the message about <userhome>/.local/bin persists

But comparing this to the real behaviour in GitHub, informed that the path is already added.

Any github action installing tools that makes is relying on the assumption that the default user installation bin dir is in the path is going to break when run via act.

@electrofelix commented on GitHub (Jan 29, 2026): Looks like part of the underlying problem is that the default `PATH` environment differs between the default runner images and what is observed with GitHub hosted runners. Extending the current medium image to have a separate user I noticed that the message about `<userhome>/.local/bin` persists <img width="612" height="116" alt="Image" src="https://github.com/user-attachments/assets/dba4a88f-3182-4da3-98d2-a530e1456f24" /> But comparing this to the real behaviour in GitHub, informed that the path is already added. <img width="888" height="150" alt="Image" src="https://github.com/user-attachments/assets/a9524d1a-a709-450f-bb87-ff72c53b607a" /> Any github action installing tools that makes is relying on the assumption that the default `user` installation `bin` dir is in the path is going to break when run via act.

kerem commented

Author

Owner

@electrofelix commented on GitHub (Jan 30, 2026):

Following https://github.com/nektos/act/issues/973#issuecomment-2457979468 and https://github.com/nektos/act/issues/973#issuecomment-2221196172 and extending to cover additional paths seems to be the best fix for this currently.

The github runner images helper scripts all modify /etc/environment github.com/actions/runner-images@1b0ec730f6/images/ubuntu/scripts/build/install-python.sh, but it appears docker run ignores any updates to such a file.

One option might be for act to always explicitly source this file for linux/macos container runners rather than relying on the docker build settling anything needed via ENV.

@electrofelix commented on GitHub (Jan 30, 2026): Following https://github.com/nektos/act/issues/973#issuecomment-2457979468 and https://github.com/nektos/act/issues/973#issuecomment-2221196172 and extending to cover additional paths seems to be the best fix for this currently. The github runner images helper scripts all modify `/etc/environment` https://github.com/actions/runner-images/blob/1b0ec730f6ed72f70433555b37001a8608b97433/images/ubuntu/scripts/build/install-python.sh, but it appears docker run ignores any updates to such a file. One option might be for act to always explicitly source this file for linux/macos container runners rather than relying on the docker build settling anything needed via `ENV`.

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Jan 30, 2026):

One option might be for act to always explicitly source this file for linux/macos container runners rather than relying on the docker build settling anything needed via ENV.

I was in favor of this code removal due to

caused act images to have missing programs in plain docker run or docker exec of a failed container
caused act to have a different env than GitHub Actions workflows usings job.container

yes older versions of act did somehow interpret /etc/environment

Now the act images interpret /etc/environment on build time instead of runtime backed into the Env metadata.

The user specfic env might live in a profile source folder? If you alter the user such path becomes outdated.

@ChristopherHX commented on GitHub (Jan 30, 2026): > One option might be for act to always explicitly source this file for linux/macos container runners rather than relying on the docker build settling anything needed via `ENV`. I was in favor of this code removal due to - caused act images to have missing programs in plain docker run or docker exec of a failed container - caused act to have a different env than GitHub Actions workflows usings job.container _yes older versions of act did somehow interpret /etc/environment_ Now the act images interpret /etc/environment on build time instead of runtime backed into the Env metadata. The user specfic env might live in a profile source folder? If you alter the user such path becomes outdated.

kerem commented

Author

Owner

@ChristopherHX commented on GitHub (Jan 30, 2026):

To clarify I thought this issue is about images that do not contain a node executable that are not especially made for act.

Those images would not have the node executable in /etc/environment, since GitHub Actions usually brings it's own node copy via bind mounts that act does not do right now.

@ChristopherHX commented on GitHub (Jan 30, 2026): To clarify I thought this issue is about images that do not contain a `node` executable that are not especially made for act. Those images would not have the node executable in /etc/environment, since GitHub Actions usually brings it's own node copy via bind mounts that act does not do right now.

kerem commented