Code execution node exception.

[Zingway]

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.11.2

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

Code execution node exception: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Failed to execute code, got status code 502, please check if the sandbox service is running )

✔️ Expected Behavior

Code execution node normal

❌ Actual Behavior

No response

[dosubot]

@Zingway the 502 status code from the sandbox service typically has a few root causes. Here are the most common ones:

1. Verify the sandbox container is running and healthy

docker compose ps sandbox
docker compose logs sandbox --tail=50

If the sandbox is crashing or restarting, the worker will get a 502 when it tries to reach http://sandbox:8194/v1/sandbox/run [1].

2. Check python_path in your sandbox config

After upgrading, the Python binary path changed from /usr/local/bin/python3 to /opt/python/bin/python3. If your docker/volumes/sandbox/conf/config.yaml still has the old path, code execution will fail [2]. Make sure it reads:

python_path: /opt/python/bin/python3

Then restart the sandbox.

3. Sandbox seccomp issues (intermittent failures)

The dify-sandbox:0.2.15 image has a regression with an incomplete seccomp syscall whitelist, causing code executions to crash mid-response [3]. The sandbox returns HTTP 200 but then disconnects, and the worker surfaces this as the generic "network issue / sandbox not running" error [4]. A fix is tracked in dify-sandbox#275. As a workaround, you can downgrade to langgenius/dify-sandbox:0.2.14 [4].

4. Ensure the sandbox is on the correct Docker network

The worker communicates with the sandbox at http://sandbox:8194. If there's a network misconfiguration (e.g., services on different Docker networks), the worker can't reach the sandbox at all.

Could you share the output of docker compose ps and docker compose logs sandbox --tail=50? That would help narrow down whether the sandbox container is healthy, crashing, or unreachable.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Zingway]

1. This is an occasional issue.

2. The detailed error log of dify api is as follows:
   ERROR [error_handler.py:101] Node 1773910518871 failed with ABORT strategy: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Failed to execute code, got status code 502, please check if the sandbox service is running )
   ERROR [workflow_entry.py:116] 741ccd314f Unknown Error when workflow entry running
   Traceback (most recent call last):
   File "xx/dify-dev/api/core/workflow/workflow_entry.py", line 112, in run
   yield from generator
   File "xx/dify-dev/api/core/workflow/graph_engine/graph_engine.py", line 292, in run
   raise self._graph_execution.error
   RuntimeError: Failed to execute code, which is likely a network issue, please check if the sandbox service is running. ( Error: Failed to execute code, got status code 502, please check if the sandbox service is running )

3. Please provide the smallest optimization measures.

[dosubot]

@Zingway Since this is occasional (not constant) and produces a 502 from the sandbox, there are two likely root causes:

1. Sandbox seccomp whitelist gaps (most likely if using dify-sandbox:0.2.15)

The dify-sandbox:0.2.15 image has an incomplete seccomp syscall whitelist. When modern glibc/CPython hits a missing syscall, the sandbox child process is killed by SIGSYS ("bad system call"), which surfaces as an intermittent failure at roughly a ~0.1% rate [1].

The smallest fix: pin the sandbox image to 0.2.14 in your docker-compose.yaml:

sandbox:
  image: langgenius/dify-sandbox:0.2.14

This approach was confirmed to resolve the issue for other users with the same symptoms [2]. An upstream fix is in progress at dify-sandbox#275 [1].

2. Stale connections in the sandbox HTTP connection pool

The sandbox client uses a persistent connection pool with keepalive_expiry=5.0 seconds by default [3]. If the sandbox drops an idle connection, the pooled client may attempt to reuse a dead connection — resulting in an intermittent error. The error message in this case would typically say "Server disconnected without sending a response" rather than a 502 status code [2].

You can reduce the keepalive expiry in your .env:

CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=2

To confirm which cause applies: check your sandbox container logs at the time of the failures. If you see process finished with error: signal: bad system call (core dumped), it's the seccomp issue [1]. If the sandbox logs show no errors but the worker still gets a 502, it's likely a connection pool issue.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Zingway]

my version of dify-sandbox is 0.2.12

[dosubot]

@Zingway Thanks for the version info. Since you're on dify-sandbox:0.2.12, the seccomp whitelist regression that affects 0.2.15 doesn't apply to you [1].

Without more detail on the specific issue you're hitting, here's what's most commonly reported with 0.2.12 — intermittent "Server disconnected without sending a response" errors. These point to stale connections in the worker's httpx connection pool [2]. The worker maintains persistent connections to the sandbox with a default keepalive_expiry of 5 seconds [3] [4]. If the sandbox closes an idle connection before that window expires, the next request on it fails.

If that matches your symptoms, you can try lowering or disabling the keepalive in your .env:

CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=2

or to disable keepalive entirely:

CODE_EXECUTION_POOL_KEEPALIVE_EXPIRY=0

Then restart your API and worker containers.

Could you share what error or behavior you're actually seeing? That will help narrow things down — for example, whether it's a connection issue, a sandbox crash, or something else entirely.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Zingway]

I checked the logs of the dify-sandbox container, and the following errors frequently appear. I'm not sure if they are related to the aforementioned issue:
2026/08/12 09:03:07 setup.go:146: [ERROR]failed to wait for the command to complete
2026/08/12 09:03:07 server.go:51: [PANIC]failed to install python dependencies: exit status 1

[dosubot]

@Zingway Yes, these errors are very likely directly related to the issues you're seeing. The log entry:

[PANIC] failed to install python dependencies: exit status 1

means the sandbox is crashing when it tries to install Python dependencies. When this panic occurs, the sandbox restarts — and any in-flight or subsequent requests during that window will fail (e.g., 502 errors or "Server disconnected without sending a response") [1].

The most common causes for this error are:

1. The sandbox can't reach PyPI. Even if your code nodes don't explicitly import extra packages, the sandbox may try to install baseline dependencies on startup. If your environment has network restrictions or no internet access, pip will fail with exit status 1, triggering the panic.

2. The /dependencies volume is misconfigured or missing. The sandbox expects the host path ./volumes/sandbox/dependencies to be mounted at /dependencies inside the container. If this volume isn't mounted or the python-requirements.txt there is malformed, the installation fails [2].

Steps to diagnose:

1. Check the full pip error in sandbox logs:

   docker logs <sandbox-container> 2>&1 | grep -A 20 "failed to install"

2. Verify your docker/volumes/sandbox/dependencies/ directory exists on the host and is mounted correctly. It can be empty if you don't need extra packages, but it must exist [2].

3. Test if the sandbox can reach PyPI:

   docker exec <sandbox-container> pip install --dry-run requests

If your environment has no internet access, configure a pip mirror in docker/volumes/sandbox/conf/config.yaml [2]:

python_pip_mirror_url: "https://your-internal-pypi-mirror/simple"

Or set the PIP_MIRROR_URL environment variable on the sandbox container (as shown in other users' docker-compose configurations) [1]. The panic and the downstream errors should both stop once pip can successfully complete.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Zingway]

According to the logs of the dify-sandbox, the following error is reported every two minutes:
2026/08/12 09:06:34 server.go:51: [PANIC]failed to install python dependencies: exit status 1
The python-requirements.txt file exists in the docker/volumes/sandbox/dependencies/ directory. Is it possible that the packages defined in the file trigger the pip installation, which in turn triggers the preceding error? The preceding error will restart the container. If the code execution node is running at this time, the problem mentioned at the beginning will occur.

[dosubot]

@Zingway Your analysis is correct — this is almost certainly the root cause of the intermittent failures. The flow is:

1. The sandbox reads python-requirements.txt from the mounted /dependencies directory [1]
2. It tries to pip install the listed packages
3. pip fails (exit status 1) — likely a network/connectivity issue reaching PyPI, or a package that can't be resolved
4. The sandbox panics and restarts
5. Any code execution request in-flight at that moment fails with a "Server disconnected without sending a response" error [2]

To see the actual pip error, run the install manually inside the container:

docker exec -it <sandbox-container> pip install -r /dependencies/python-requirements.txt

This will show the real error being swallowed by the panic log.

Most likely fix — configure a pip mirror in docker/volumes/sandbox/conf/config.yaml. The example config already has this field [3]:

python_pip_mirror_url: https://pypi.tuna.tsinghua.edu.cn/simple

You can also set this via the PIP_MIRROR_URL environment variable [1]. Replace it with a mirror accessible from your environment, or your internal PyPI mirror if you're in a restricted network.

Alternative — if the packages in python-requirements.txt are not strictly necessary, you can empty the file to stop the repeated install attempts and panics. The sandbox will still work for code nodes that only use the Python standard library.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.