Harden daemon: socket permissions, env safety, telemetry, rewrite locking

[jwiegley]

• Set umask(077) before creating control/trace sockets to prevent
  TOCTOU race with subsequent chmod
• Set daemon directory permissions to 0700
• Move env var sanitization before tokio runtime build to avoid
  unsafe env modification from worker threads
• Track dropped telemetry envelopes and CAS records via atomic
  counters, expose in FamilyStatus
• Make watermark update a confirmed operation via oneshot channel
• Scope watermark pruning to the correct worktree prefix
• Add file locking for rewrite log read-modify-write cycles

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

[jwiegley]

• Add wall-clock timeout and SSH hardening to authorship note fetch #1184
• Add attribution test writing guidelines to AGENTS.md #1033
• Add integration tests for Graphite operations and missing attribution #1032
• Replace silent error swallowing with debug logging #1031
• Refactor CheckpointKind API and improve attribution/storage performance #1030
• Harden daemon: socket permissions, env safety, telemetry, rewrite locking #1029 👈 (View in Graphite)
• Fix security: credential permissions, CAS validation, token redaction #1028
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 13 additional findings in Devin Review.

[devin-ai-integration]

🟡 Rewrite log lock falls through on contention, defeating its purpose

The new acquire_rewrite_lock function at src/git/rewrite_log.rs:579-590 retries lock acquisition 3 times (~200ms total), then proceeds without the lock if all attempts fail. This defeats the purpose of the lock in exactly the scenario it's designed to protect against: when another process is performing the read-modify-write cycle. Process A holds the lock and is writing; Process B fails to acquire it 3 times, then proceeds lockless — both processes read the same file content, and one process's event is silently lost when the other overwrites it. The lock should either return an Err to the caller or block with a longer timeout rather than silently proceeding unprotected.

Prompt for agents

The function acquire_rewrite_lock in src/git/rewrite_log.rs:579-590 returns None when the lock cannot be acquired after 3 attempts. The caller at line 537 assigns it to _lock and proceeds with the read-modify-write regardless. This silently downgrades to no-lock mode precisely when another writer holds the lock, creating the race condition the lock was meant to prevent.

Two approaches to fix:
1. Return an error instead of None when the lock cannot be acquired, and propagate it to the caller. This is the safest approach but may cause failures in edge cases.
2. Increase the retry count and/or sleep duration significantly (e.g., 10 retries with 200ms sleep = 2 seconds total) so the fallback is only triggered in truly pathological cases, not during normal concurrent access.

The current 3 attempts with 100ms sleep (200ms total budget) is too tight for the lock to be meaningful — a concurrent writer doing file I/O on a slow filesystem could easily hold the lock for longer than 200ms.

---

Was this helpful? React with 👍 or 👎 to provide feedback.