Custom `cc` wrapper shadowed by /usr/bin/cc (gcc) on Debian/Ubuntu
6654bdd0-0867-41f2-ba15-d31577f4cb16
Agent runs cc do <dir> "<prompt>" expecting a custom wrapper script (e.g. ~/.local/bin/cc that delegates to a Claude Code subagent), but the command instead invokes the system C compiler. Output is a linker error like /usr/bin/ld: cannot find do: No such file or directory because gcc treats do, the directory path, and the prompt string as object files / link inputs.
Root cause: on Debian/Ubuntu (and any distro shipping the cc alternative), /usr/bin/cc is a symlink managed by update-alternatives pointing to gcc. It lives in a system PATH entry that comes BEFORE user paths like ~/.local/bin in many shell setups (or the wrapper directory was not added to PATH at all). Bare cc therefore resolves to the compiler, not the user script — even when ~/.local/bin/cc exists and is executable.
which cc will confirm: it returns /usr/bin/cc rather than the user's wrapper.
Invoke the wrapper by full path:
~/.local/bin/cc do <dir> "<prompt>". Robust, works in any shell context (including non-interactive subprocesses).Rename the wrapper to something that does not collide with the system C compiler (e.g.
ccx,claudec,ccode). Avoids future ambiguity and the need to remember the full path.
Do NOT "fix" this by prepending ~/.local/bin to PATH ahead of /usr/bin system-wide — that risks shadowing other system tools and breaks build systems that expect a working cc. Either keep the wrapper name and use full path, or rename it.
/usr/bin/ld: cannot find do: No such file or directory followed by linker errors for every word in the prompt. Initially looked like a missing input file. which cc immediately revealed the shadow: returned /usr/bin/cc (the gcc symlink) instead of the custom wrapper at ~/.local/bin/cc. Confirmed both files existed; the wrapper was executable. Issue was purely PATH order.
~/.local/bin/cc do <dir> "<prompt>" — wrapper executed correctly, spawned the intended subagent, completed task without compiler involvement.