On update: "error: cannot write to ~/.local/bin/codebase-memory-mcp"

[gaia]

codebase-memory-mcp update (current: 0.5.2)

Which binary variant do you want?
  1) standard  — MCP server only
  2) ui        — MCP server + embedded graph visualization
Choose (1/2): 1

Downloading standard binary for linux/amd64 ...
  https://github.com/DeusData/codebase-memory-mcp/releases/latest/download/codebase-memory-mcp-linux-amd64.tar.gz
################################################################################################################# 100.0%
error: cannot write to /home/user/.local/bin/codebase-memory-mcp

$ ll /home/user/.local/bin/codebase-memory-mcp
-rwx------ 1 user user 129M Mar 20 05:32 /home/master/.local/bin/codebase-memory-mcp*

$ codebase-memory-mcp --version
codebase-memory-mcp 0.5.5 # After manual update

didn't have this issue in the previous version. never had to use sudo. removing and reinstalling didn't help.

BTW original permissions were 500. set it to 700 to see if the issue went away. is it supposed to be 500 (after this gets solved)?

[gaia]

Root cause

The v0.5.5 security hardening likely introduced this regression. Specifically:

Shell injection elimination — replaced system() calls with cbm_exec_no_shell() (fork+execvp), no tainted data reaches a shell
TOCTOU race fixes — atomic file permissions, open-then-fstat pattern

Previously the update probably used system() to shell out to cp or mv to replace the binary — which works even when the binary is currently being executed, because the shell command runs in a separate process. With the switch to direct file I/O (open/write/fstat), the write fails because the running process (the MCP server started by Claude Code) holds the binary open.

On Linux, you can't write to an executable that's currently running (ETXTBSY), but you can atomically replace it via rename() — write to a temp file in the same directory, then rename() it over the original. The running process keeps its file descriptor to the old (now unlinked) inode, and the new binary takes effect on next launch.

Suggested fix

Replace the direct write with:

1. Write the new binary to a temp file in the same directory (e.g. ~/.local/bin/.codebase-memory-mcp.tmp)
2. chmod the temp file with the desired permissions
3. rename() the temp file over the original (atomic, works even while the original is executing)

Workaround

Manually replace the binary while the MCP server isn't running:

curl -L -o /tmp/cbm.tar.gz https://github.com/DeusData/codebase-memory-mcp/releases/latest/download/codebase-memory-mcp-linux-amd64.tar.gz \
  && tar xzf /tmp/cbm.tar.gz -C /tmp \
  && cp -f /tmp/codebase-memory-mcp ~/.local/bin/codebase-memory-mcp \
  && chmod +x ~/.local/bin/codebase-memory-mcp \
  && rm /tmp/cbm.tar.gz /tmp/codebase-memory-mcp \
  && codebase-memory-mcp --version

[DeusData]

Confirmed — this is a real bug in the update command. The binary is opened with O_WRONLY | O_CREAT | O_TRUNC which fails if the existing file has no write permission (e.g. 500/-r-x------).

The fix is to unlink the old binary before writing the new one, which also avoids issues with replacing a running binary on some systems. Tracking for the next release.

Regarding permissions: the binary should be 755 (-rwxr-xr-x) after install. 500 would only happen if something explicitly changed it. After this is fixed, the new binary will be created with 0755.

[DeusData]

Fixed in commit 8fc1949: added cbm_replace_binary() which unlinks the existing file before writing. unlink() only requires write permission on the parent directory, not the file itself, so read-only binaries (0500, 0555) are now handled correctly.

TDD: two tests added — overwrite read-only file and create new file. Verified on Linux arm64 (Docker ASan+LeakSan), Windows (cross-compile), and macOS arm64 (native). Will be included in the next release.

Thanks @gaia for the detailed bug report with the exact error output and permission investigation!