I keep seeing this in agent-written PRs.
The deploy failed with permission denied. The container couldn't write the upload dir. The agent "fixed" it. CI is green. Then you open the diff and the real change is chmod 777, chmod -R a+rwx, a world-writable volume, or USER root so the process can touch everything. Green because nothing is denied anymore.
You did not ask for a world-writable tree. You asked why the app user could not write that one path — wrong UID in the image, a missing chown in the entrypoint, a volume mounted read-only, or a directory that should live under /tmp with the right owner.
The 60-second check I run now
When an agent PR claims to fix permission denied, EACCES, "read-only file system", or upload/write failures:
- Diff the "fix." Did it set a narrow owner/mode on the one path that needs it, or did it open the tree to everyone (777 / a+rwx / root)?
- Ask who can still write that path after merge. If the answer is "anyone on the host" or "the whole container as root," bounce it.
- If the only change is chmod 777 / world-writable / run-as-root — especially with no note about the intended UID — I reject it until the real ownership story is owned.
This is one of the stops on a short bar I use before I merge agent PRs. Free one-pager if you want the rest: https://chopragunji.gumroad.com/l/zpnmdn
If you'd rather someone else do a hard pass on one scary AI PR, I still have founding slots at $49 (normally $99): https://chopragunji.gumroad.com/l/byoyi/FOUNDING
Have you merged an agent "permission fix" that was really just chmod 777?
Top comments (0)