Test suite assumes umask 022: activation-transaction fixtures fail on umask 002 machines #1483

Version

codebase-memory-mcp dev (source build, main @ 0d6f26a)

Platform

Linux (x64)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

Running the canonical suite (scripts/test.sh) on a stock Debian machine fails 12 tests across test_cli and test_daemon_frontend, all with activation transaction I/O failed (some with the target-entry-snapshot refusal breadcrumb) or daemon fixtures dying under SIGKILL. The same suites are green in CI.

Root cause: the machine uses umask 002 (Debian's user-private-group default), so every file, fixture directory, and the linked build/c/test-runner binary is born group-writable. The activation-transaction tamper defenses (activation_posix_entry_snapshot_with_links in src/cli/activation_transaction.c: (mode & 0022) != 0, hard-link count, ACL checks) then refuse the staged candidate/target. The defense is working as designed — but the test fixtures and the build never normalize their modes, so it fires on legitimate test artifacts whenever the developer's umask is not 022.

Expected: the suite passes regardless of the developer's umask — e.g. scripts/test.sh sets umask 022 for both the build and run legs, or the fixtures chmod what they stage.

Reproduction

1. Code: this repository @ 0d6f26a (no indexing involved — pure test-suite run).
2. Command, on any Linux account whose umask is 002 (stock Debian user-private-group setup): scripts/test.sh --suites cli,daemon_frontend (the full scripts/test.sh shows the same 12 failures).
3. Result: 9 test_cli install/uninstall tests fail (error: failed to stage install candidate: activation transaction I/O failed: target-entry-snapshot (os 0) → e.g. FAIL tests/test_cli.c:941: install_rc == 1, expected 0 == 0), plus test_daemon_frontend backpressure fixtures whose daemon is reaped with daemon_signal=9. Expected: all green, as in CI (umask 022).

Verified in both directions on the same machine:

• Re-running with umask 022 && scripts/test.sh --suites cli,daemon_frontend fixes the fixture-directory failures (12 → 5; all daemon_frontend green).
• The remaining 5 need chmod g-w build/c/test-runner first: the incremental build does not re-link the runner, so the binary keeps the group-writable 775 mode from the earlier umask-002 build, and the activation snapshot (correctly) refuses it as the install candidate. After that: everything passes.

Suggested fix: set umask 022 near the top of scripts/test.sh (covering both build and run), or have the activation fixtures explicitly chmod the directories/binaries they stage.

Logs

umask 002 run (suites cli,daemon_frontend,subprocess in isolation):
  cli_activation_quiesce_does_not_wait_on_bootstrap_startup  error: failed to stage install candidate: activation transaction I/O failed
  FAIL tests/test_cli.c:941: install_rc == 1, expected 0 == 0
  cli_install_force_quiesces_active_cohort_before_replacing_binary  error: failed to stage install candidate: activation transaction I/O failed: target-entry-snapshot (os 0)
  FAIL tests/test_cli.c:989: rc == 1, expected 0 == 0
  cli_uninstall_quiesces_active_cohort_before_removing_binary_and_index  error: failed to stage uninstall transaction: activation transaction I/O failed
  daemon_frontend_stdout_backpressure_eof_fail_stops_and_cancels_session  frontend backpressure fixture failed: ... daemon_reaped=1 daemon_status=0x9 daemon_exit=-1 daemon_signal=9 ...
  FAIL tests/test_daemon_frontend.c:1354: ASSERT(frontend_backpressure_run_isolated(0))
  290 passed, 12 failed

umask 022 run, binary still 775 from the previous build:
  296 passed, 6 failed   (all remaining failures in test_cli install staging)

umask 022 + chmod g-w build/c/test-runner:
  cli/daemon_frontend fully green

$ umask
002
$ stat -c '%a' build/c/test-runner   # linked under umask 002
775

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.