`uv run` fails with `<(...)` process substitution

[Bobronium]

Summary

Opening this as a bug report since python supports this:

~
❯ python <(echo 'print(__name__)')
__main__

~
❯ uv run <(echo 'print(__name__)')
error: Failed to spawn: `/dev/fd/11`
  Caused by: Permission denied (os error 13)

Use case (similar to #6862)

uv run <(pbpaste)

Workaround

uv run python <(echo 'print(__name__)')

References

pipx has the same issue pypa/pipx#1292 with potential fix being pypa/pipx#1293

Platform

Darwin 24.1.0 arm64

Version

uv 0.7.2 (481d05d 2025-04-30)

Python version

Python 3.12.7

[legendre6891]

uv help run has this snippet

When used with a file ending in .py or an HTTP(S) URL, the file will be treated as a script and run with a Python interpreter, i.e., uv run file.py is equivalent to uv run python file.py. For URLs, the script is temporarily downloaded before execution. If the script contains inline dependency metadata, it will be installed into an isolated, ephemeral environment. When used with -, the input will be read from stdin, and treated as a Python script.

The issue is that <(echo 'print(__name__)') is evaluated to /dev/fd/XXX by the shell (in your example, it is /dev/fd/11). The string /dev/fd/XXX does not end in .py and nor is it an URL. Therefore, /dev/fd/XXX is treated as the name of the tool; when uv run runs exec on this path, the file /dev/fd/XXX is not executable and you see the permission denied error.

In addition to your workaround, note also

When used with -, the input will be read from stdin, and treated as a Python script.

Thus, the following two methods should also work (it redirects /dev/fd/XXX to stdin).

cat <(echo 'print(__name__)') | uv run -

uv run - < <(echo 'print(__name__)')

---

All this to say, the behavior you observe is consistent with the documentation. That said, perhaps uv run could be improved to have smarter handling in this scenario...