Introduction

The error docker exec failed: 'cd': executable file not found in PATH usually means Docker is doing exactly what you asked, but not what you intended. docker exec tries to launch a program inside the container, and cd is not a standalone program. It is a shell built-in, so Docker cannot execute it directly unless you run it through a shell.

Why cd Fails With docker exec

When you run a command such as this:

docker exec my-container cd /app

Docker looks for an executable named cd inside the container's PATH. There is no such binary in normal Linux images, because directory changes are handled by the shell process itself.

That is why the command fails even though cd works fine in an interactive shell session.

The Correct Fixes

If you need to change directories and then run another command, execute a shell explicitly:

docker exec my-container sh -lc 'cd /app && ls -la'

If the image includes Bash, this also works:

docker exec my-container bash -lc 'cd /app && python app.py'

A cleaner option for many cases is Docker's working-directory flag. This avoids the shell built-in entirely:

docker exec -w /app my-container ls -la

That is usually the best solution when you just want the command to start in a specific directory.

Choosing Between sh -lc And -w

Use -w when you only need to set the working directory for a single command. It is simple, shell-independent, and easier to read.

Use sh -lc when you need full shell behavior such as chaining commands, environment-variable expansion, pipes, or conditionals.

docker exec my-container sh -lc 'cd /app && export MODE=debug && ./run-tests.sh'

Minimal images often include sh but not bash, so sh -lc is usually the safer default unless you know Bash is installed.

A Practical End-To-End Example

Suppose you want to inspect files in /usr/src/app, then run a script there. These are the two clean versions of that workflow:

docker exec -w /usr/src/app my-container ls -la

docker exec my-container sh -lc 'cd /usr/src/app && ./migrate.sh'

The first command is best when directory selection is the only concern. The second is better when later commands depend on shell syntax or multiple steps.

That distinction helps keep operational scripts readable. If every command is wrapped in a shell when it does not need one, the script becomes harder to debug.

Inspecting What The Container Actually Has

If a command still fails, check which shells and directories exist inside the image.

1docker exec my-container which sh
2docker exec my-container which bash
3docker exec my-container pwd
4docker exec my-container ls /

This is especially useful with Alpine-based or distroless images, where the shell environment may be different from a standard Debian or Ubuntu container.

Common Pitfalls

The most common mistake is treating docker exec as if it automatically runs inside a shell. It does not. It executes the command directly unless you explicitly ask for a shell.

Another issue is assuming Bash exists. Many small images only provide /bin/sh, so bash -lc may fail even if the cd problem is fixed.

It is also easy to forget that each docker exec call starts a new process. Changing directories in one exec session does not affect the next one.

Finally, if you always need a particular working directory, consider setting WORKDIR in the Dockerfile so runtime commands start from a sensible default.

Summary

• 'cd is a shell built-in, not a standalone executable.'
• 'docker exec container cd /path fails because Docker tries to execute cd directly.'
• Use docker exec -w /path container command when you only need a working directory.
• Use sh -lc or bash -lc when you need shell features such as cd && command.
• Check whether the image actually contains the shell you are trying to use.