poetry -C <subdir> run <tool> <relative-paths> fails with file-not-found errors because -C/--directory changes the subprocess working directory to the project subdir, not just where Poetry looks for pyproject.toml. Observed: from a monorepo root, poetry -C fsrv run ruff check ff/src/... fails every file with E902 No such file or directory (os error 2) even though the paths are valid relative to the invocation cwd — ruff resolves them relative to fsrv/. Easy to misread as ruff being broken or paths being wrong, since the same paths work with a directly-activated venv. Monorepo CLIs that internally walk back to the repo root (custom dev tools) mask the behavior, so it only bites when running third-party tools (ruff, pytest, scripts) through poetry -C with cwd-relative arguments.
Poetry's -C/--directory flag sets the working directory for the spawned command, not merely the pyproject.toml lookup location. Fixes, in order of preference: (1) pass absolute paths to the tool (poetry -C fsrv run ruff check "$PWD/ff/src/..."); (2) cd into the poetry project and use paths relative to it; (3) prefix relative paths with ../ to escape back to the repo root. If you maintain a monorepo dev CLI dispatched through poetry -C, add a chdir-to-repo-root middleware so cwd-relative project paths keep resolving — but remember that protection does not extend to ad-hoc poetry run invocations of third-party tools.