Confirm a container binary has execute permission before running it
You will check that the binary inside your container has execute permission and is the version you expect before you launch it. This prevents silent failures and running something you did not intend to run.
- Locate binary in imageUse the path inside the container image
- Inspect mode and ownerExecute bit set for the running user
- Verify versionMatch the pinned release or checksum
- Test in throwaway containerNo secrets, minimal mounts
Why it matters
A permission that looks granted is not always the one the tool needs. One Cloudflare MCP user had full access selected in the picker, yet three scopes were missing and calls failed until the grant was reset (issue 170 (opens external site)). A Google Sheets create call failed because a second API step needed its own scope (issue 22 (opens external site)). Checking what a binary actually has, rather than what you assume, catches these gaps early.
Steps
- Identify the exact binary path inside the image you will run. Do not check the copy on your host, because it can differ from the image.
- From inside a container started from that image, inspect the file's mode and owner. Confirm the execute bit is set for the user who will run it, not only for root.
- If the execute bit is missing, decide whether it should be there at all. Fix it in your image build instead of adding execute permission at runtime, so the problem stays visible.
- Confirm the binary's version or checksum matches the release you meant to install, and pin that version in your build.
- Run the binary once in a throwaway container with no secrets in its environment and only the mounts it truly needs.
- Only after that test, wire the binary into your MCP configuration with the smallest set of permissions it needs. A permission list proposed for mcp-jetbrains is a starting point and has not been officially validated, so extend it only when your workflow requires it (issue 75 (opens external site)).
Common mistakes
- Checking the binary on your host machine instead of the image that actually runs.
- Using chmod at container start to hide a missing execute bit, which masks the build problem.
- Passing API keys or tokens into the first test run, when a throwaway run needs none of them.
- Assuming a UI showing full access means every underlying permission was granted.
Checklist
0 of 8 done