Question：custom tool use and sandbox dep

[ToWorld]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

I have two questions:

1. When creating a custom tool, how do I dynamically specify the server's domain name or IP:port? Currently, it seems only some request parameters can be passed;

2. For sandboxes, Python 3, and JavaScript, what common packages are installed in the image? I will be connecting to a non-Dify sandbox, and these packages need to be installed.

Looking forward to your reply.

[dosubot[bot]]

Hi @ToWorld, here's what I found for your two questions:

1) Dynamic Server URL in Custom Tools

Custom tools in Dify do not support dynamically parameterizing the server domain/IP:port at invocation time. The server URL is fixed when you define the tool's OpenAPI schema — it's taken from the servers[0].url field and concatenated with the API path [1].

The only built-in flexibility is environment-based server selection: if you define multiple entries in the servers array with an env field, Dify can select the matching one via the X-Request-Env header. But you still need to pre-define all possible server URLs in the schema.

Workaround options:

• Define multiple server entries in your OpenAPI spec for different environments.
• Use a reverse proxy or gateway with a stable address that routes to your actual backends.
• If you truly need runtime-dynamic URLs, consider using a Code node in a workflow to make the HTTP request directly instead of a custom tool.

2) Pre-installed Sandbox Packages

The Dify sandbox uses a minimal installation approach — no application-level Python or JavaScript packages are pre-installed beyond the standard library. Here's what's included:

Runtimes & Package Managers:

• Python 3.12 + uv 0.8.9 (package manager)
• Node.js 22.22.1 + pnpm 11.9.0

System Utilities:

• git, tmux, curl, ripgrep, jq, openssh-client, file, zip/unzip, xz-utils, less, procps

[2]

No pre-installed pip/npm packages like numpy, pandas, requests, etc. are bundled. Users can install dependencies at runtime using pip/uv for Python or npm/pnpm for Node.js.

If you're connecting a non-Dify sandbox, you'd mainly need to provide Python 3.12, Node.js 22, and ensure the package managers are available so code can install dependencies on the fly. The Dify sandbox also pre-initializes jinja2 for template rendering [3], so that's worth including as well.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ToWorld]

If you're connecting a non-Dify sandbox, you'd mainly need to provide Python 3.12, Node.js 22, and ensure the package managers are available so code can install dependencies on the fly

What if we use dynamic package installation? Since the code execution node request is synchronous and blocking, won't it time out?

[dosubot[bot]]

Good question — yes, timeout is a real concern here. The sandbox's default worker timeout is only 15 seconds (SANDBOX_WORKER_TIMEOUT) [1], and package installations via pip/npm are subject to that same timeout. Installing packages at runtime will very likely exceed 15 seconds and get killed.

Options to mitigate this:

1. Increase timeouts — You can raise SANDBOX_WORKER_TIMEOUT (sandbox-side) and CODE_EXECUTION_READ_TIMEOUT (API-side, default 60s) via environment variables [2]. But this makes all code executions wait longer on failure, which isn't ideal.

2. Pre-install packages in the image — This is the more robust approach. If you're running your own non-Dify sandbox, bake the packages you need into the container image so they're available immediately at execution time. No install step, no timeout risk.

3. Use a local PyPI/npm mirror — If you must install at runtime, setting PIP_MIRROR_URL [3] to a local mirror can significantly reduce download time, but it still may not fit within a 15-second window for larger packages.

For a production setup, pre-installing dependencies in the image is strongly recommended over dynamic installation.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.