macOS: Envoy bootstrap silently skips dep install + PyPI native wheels blocked by TD Python's Library Validation

[diegochavez-io]

Summary

On a fresh install of Embody v5.0.392 on macOS, enabling Envoyenable produces:

Traceback (most recent call last):
  File "/sys/TDResources/threadManager/ThreadManagerExt", line 641, in forceImmediate
  File "/project1/Embody/EnvoyExt", line 1866, in _runServer
RuntimeError: MCP server failed on port 9870: No module named 'mcp.server'
EnvoyExt: Envoy disabled

This is two stacked problems, one user-visible and one that becomes visible only if you fix the first.

Environment

Embody	v5.0.392
TouchDesigner	2025.32280
Bundled Python	3.11.10 (heads/3.11-Derivative-dirty:e60cd070d8, Oct 10 2024)
macOS	26.4.1 (build 25E253), Apple Silicon
uv	0.10.5 (already installed)

Problem 1 — Bootstrap creates .venv but installs no deps

After dragging in the .tox and toggling Envoyenable:

• .venv/ is created next to the .toe ✅
• .mcp.json is written ✅
• .venv/lib/python3.11/site-packages/ is empty ❌ — no mcp, no pydantic, no httpx, nothing
• Envoy then tries to import mcp.server and crashes

The bootstrap appears to skip the dep-install step entirely on this machine. No error message in the textport before the mcp.server traceback. Possible silent failure inside _setupEnvironment / _findOrInstallUv — not surfaced to the user.

Problem 2 — Even after manual uv pip install, native wheels fail to load

Reproducing the dep install manually:

VIRTUAL_ENV=/path/to/project/.venv uv pip install "mcp[cli]"
.venv/bin/python -c "import mcp.server"

…gets:

ImportError: dlopen(.../pydantic_core/_pydantic_core.cpython-311-darwin.so):
code signature ... not valid for use in process:
mapping process and mapped file (non-platform) have different Team IDs

TD's bundled python3.11 is signed by Derivative's Apple Team ID and runs under Hardened Runtime + Library Validation. PyPI prebuilt wheels for pydantic_core, cffi, rpds, and cryptography._rust are signed by their respective publishers, so the dynamic loader rejects them.

codesign --force --sign - (ad-hoc resigning) does not bypass Library Validation — same error after.

Workaround that works locally

Compile all native deps from source against TD's Python:

# Install Rust toolchain
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain stable --profile minimal
source "\$HOME/.cargo/env"

# Reinstall with --no-binary so .so files are built locally
VIRTUAL_ENV=/path/to/project/.venv uv pip install --no-binary :all: --reinstall "mcp[cli]"

After that, import mcp.server succeeds and Envoy starts cleanly.

Suggested fix

1. Surface bootstrap failures. If _setupEnvironment exits non-zero or doesn't install deps, log that explicitly to the textport before _runServer is allowed to run. The current behavior leaves users with an empty venv and an inscrutable No module named 'mcp.server' error.
2. Detect the macOS Library Validation case. When running on macOS under TD's bundled Python, default uv pip install to --no-binary pydantic-core,cryptography (at minimum), or document the Rust-toolchain prerequisite for Mac users. Ad-hoc resigning is not an option.
3. Document the Rust prereq somewhere in the install flow if option 2 is the chosen path. Most TD users won't have cargo on their machine.

Happy to test a fix or send a PR if helpful.

[diegochavez-io]

Correction on Problem 2: I was wrong about Library Validation being a wall. TouchDesigner.app is signed with the com.apple.security.cs.disable-library-validation entitlement (verified via codesign -d --entitlements :- /Applications/TouchDesigner.app), so PyPI prebuilt wheels for pydantic_core, cffi, cryptography, etc. load fine inside TD's process. The Team-ID-mismatch error only appears when running .venv/bin/python directly from terminal because the standalone python3.11 binary in TD's framework has no entitlements file at all and inherits the strict default.

So this is only Problem 1 — bootstrap silently skipping dep install. Once deps are present in .venv (uv pip install "mcp[cli]" with normal binary wheels), Envoy starts cleanly on macOS.

The fix scope reduces to: make the bootstrap actually install deps, and surface failures. The Rust toolchain / --no-binary workaround in my original report is unnecessary on Mac.

[dylanroscover]

thanks for the entitlements correction — confirmed on my end.

can't repro problem 1 here though. clean v392 drop on macos works, and running embody's bootstrap subprocess sequence (uv venv + uv pip install) against td's bundled python populates site-packages cleanly. environment-specific.

to narrow it down:

1. full textport above the traceback — _setupEnvironment logs installing dependencies... or environment setup failed: <stderr>. which one shows?
2. from td's textport: import shutil; print(shutil.which('uv')) — gui apps don't inherit shell path, so ~/.local/bin/uv may be invisible to td.
3. state of .venv/ after failure — is bin/python present? site-packages/ truly empty?

going to harden the silent-skip path either way so future failures surface a useful message instead of No module named 'mcp.server'.

[dylanroscover]

shipped in v5.0.393: https://github.com/dylanroscover/Embody/releases/tag/v5.0.393

_setupEnvironment now returns bool, all four previously-silent failure paths log explicit errors, Start() aborts before _runServer if deps aren't ready, and a final import mcp.server gate catches partial installs. if you hit this again on a different machine you should get a useful textport message naming the underlying failure instead of No module named 'mcp.server'.

leaving this open until you confirm the fix surfaces the right error on your end — happy to dig further once we have the actual reason your install silently skipped deps. closing otherwise.

[dylanroscover]

Bumping this — we're now on v5.0.413 with the v393 surfacing fix in place. If you (or anyone hitting this) can grab fresh textport output on a failing install, I'd love to find the actual silent-skip cause. Otherwise I'll close this in a week as superseded by the diagnostic hardening.