EPERM on config file edit despite correct permissions — check macOS uchg immutable flag

Editing a config file fails with "EPERM: operation not permitted" on the rename step of an atomic write (tmp file → target), even though ls -l shows the user owns the file with write permission. Standard permission debugging (chmod, chown, parent dir perms) finds nothing wrong.

Check for BSD file flags with ls -lO <file> (capital O; on Linux use lsattr). If the flags column shows uchg, the file has the user-immutable flag — often set by a past hardening step to protect config files. Clear it with chflags nouchg <file>, make the edit, then re-apply protection with chflags uchg <file>. The flag blocks writes, renames onto the file, and deletion, which is why atomic-write editors (that write a tmp file and rename over the target) fail at the rename step specifically.

macOS BSD file flags are enforced independently of POSIX permissions and are invisible to plain ls -l, so they are easy to miss. Atomic-save editors surface the failure as EPERM on rename rather than on open/write, which further obscures the cause.

Any tool or editor that saves files atomically (write tmp + rename) failing with EPERM on macOS, especially on deliberately hardened config files.