fix: prevent daemon privilege mismatch broken state

[svarlamov]

Summary

• Partially addresses [Bug]: Daemon lock file not recovered after macOS sleep/wake kills daemon (async mode) #1041
• Adds privilege de-escalation at daemon startup: Unix drops root via setuid/setgid when SUDO_UID/SUDO_GID detected; Windows respawns with linked (non-elevated) token via CreateProcessWithTokenW
• Adds daemon_allow_root feature flag (default false) for CI/container environments that legitimately run as root
• Relaxes daemon socket permissions from 0o600 to 0o660 so same-user processes at different privilege levels can connect
• Replaces opaque "lock held" errors with smart diagnostics: detects dead processes (auto-cleans stale files) and privilege mismatches (shows platform-specific fix commands)

Problem

When the daemon is started as a privileged user (root/admin), non-privileged users get stuck in an unrecoverable loop: can't connect (socket perms), can't start new daemon (lock held), can't kill old daemon (insufficient privileges).

Solution

Four-layer defense:

1. De-escalation — daemon drops privileges before acquiring lock
2. Permission relaxation — sockets accessible across privilege levels
3. Detection — actionable error with platform-specific fix command
4. Recovery — auto-cleans stale locks from dead processes

Test plan

• Unit tests for PID status detection (dead process, alive process)
• Unit test for privilege check when not elevated
• Integration test for stale lock auto-recovery
• Full test suite passes
• Lint and format pass
• CI: Ubuntu checks pass
• CI: Windows checks (linked token path exercised)

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 2 potential issues.

View 4 additional findings in Devin Review.

[devin-ai-integration]

🔴 Privilege de-escalation doesn't update HOME or recompute DaemonConfig, causing daemon failure on Linux

After setuid() drops root privileges, the HOME environment variable is not updated and the DaemonConfig (already computed before de-escalation) still points to root's home directory paths. On Linux, sudo changes HOME to /root by default. The flow is: handle_run() resolves DaemonConfig using home_dir() which reads HOME=/root (src/commands/daemon.rs:182), then passes it to run_daemon(config). Inside run_daemon, privileges are dropped (src/daemon.rs:8436-8441), but config still contains paths like /root/.git-ai/internal/daemon/. The subsequent DaemonLock::acquire(&config.lock_path) at src/daemon.rs:8444 tries to create/open a file in root's directory as the now-non-root user, which fails with permission denied. This defeats the entire purpose of the privilege de-escalation feature on Linux systems.

Prompt for agents

The privilege de-escalation in check_and_deescalate_privileges() (src/privilege.rs) drops root via setuid/setgid and clears SUDO_* env vars, but does NOT update the HOME environment variable to the real user's home directory. Since DaemonConfig is computed in handle_run() (src/commands/daemon.rs:182) BEFORE run_daemon() calls check_and_deescalate_privileges() (src/daemon.rs:8436), the config paths are already resolved using root's HOME.

Two things need to happen:
1. After setuid(), update HOME to the real user's home directory. You can look it up via libc::getpwuid_r(uid) to get the passwd entry, or simply use the dirs crate which internally calls getpwuid after the UID has changed.
2. The architectural issue is that DaemonConfig is computed before de-escalation. Either: (a) move privilege de-escalation to happen before DaemonConfig resolution in handle_run(), or (b) have run_daemon() recompute the DaemonConfig after de-escalation by calling DaemonConfig::from_env_or_default_paths() again. Option (a) is cleaner - call check_and_deescalate_privileges() at the start of handle_run() before daemon_config_from_env_or_default_paths().

---

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

[devin-ai-integration]

🔴 Windows respawn uses current_exe() instead of current_git_ai_exe(), risking git shim fork bomb

The respawn_deescalated_windows() function at line 227 uses std::env::current_exe() to determine the binary path for respawning. However, the codebase explicitly warns against this pattern in spawn_daemon_run_detached (src/commands/daemon.rs:414-417): when the current exe is the git shim (e.g. ~/.local/bin/git), current_exe() returns the shim path, causing the respawned process to enter handle_git() instead of handle_git_ai(), which can cause a fork bomb. The respawn should use crate::utils::current_git_ai_exe() to resolve through symlinks.

Suggested change

	let exe_path =
	std::env::current_exe().map_err(|e| format!("failed to get current exe: {}", e))?;
	let exe_path = crate::utils::current_git_ai_exe()
	.map_err(|e| format!("failed to get current git-ai exe: {}", e))?;

---

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