Dev-container entrypoints mangle quoted commands and discard --workdir (su -c "$*")
The dev containers' entrypoints re-execute their command via exec su -c "$*" owner after an unconditional cd:
images/nodejs/entrypoint.sh—cd /opt/talkyard/server…exec su -c "$*" ownerimages/app/entrypoint.dev.sh—cd /opt/talkyard/app…exec su -c "$*" owner(the files even note they're duplicates of each other,[7GY8F2])
Because "$*" joins all arguments into ONE space-separated string, two things silently break:
1. Quoted payloads get re-parsed. docker compose run --rm nodejs sh -c 'cd to-talkyard && pnpm run build' arrives in the container as three args — but after "$*" flattening, the shell su starts sees sh -c cd to-talkyard && pnpm run build, i.e. sh -c "cd" (a no-op) followed by pnpm run build in the repo root. Any argument containing spaces has the same problem.
2. --workdir is discarded. The entrypoint's unconditional cd overrides whatever working directory docker compose run --workdir … set.
How it bit for real: while containerizing the to-talkyard build (Makefile target running pnpm in the nodejs container instead of host yarn), the recipe run --rm nodejs sh -c 'cd to-talkyard && pnpm install && pnpm run build' worked on every warm machine — to-talkyard/dist/ already existed, so make skipped the target — and then failed on the first cold CI machine with a confusing ERR_PNPM_NO_SCRIPT Missing script: build, because pnpm was running in the repo root. The --workdir variant failed identically.
Pattern that avoids it (works today, no image changes): pass a single script-path argument — one token survives the flattening, and the script does its own cd:
make-recipe: $(d_c) run --rm nodejs s/impl/build-to-talkyard.sh
Possible upstream fix, if wanted: preserve argv instead of flattening — e.g. exec setpriv --reuid owner --regid owner --init-groups "$@" or gosu (exec gosu owner "$@" — the entrypoint's own comment already mentions gosu is what the postgres image uses). Either keeps quoting AND the caller's working directory intact. su --preserve-environment doesn't help here; it's the -c "$*" re-parse that loses the structure.
Low urgency — nothing in the current build hits it (host-run recipes pass single commands) — but it's a latent trap for any future containerized recipe, and the failure mode (commands silently running in the wrong directory) is expensive to debug from CI logs.
(Found during the Docker-only build harness work — same effort as PRs #747/#748/#749.)