I Stopped Testing APX in the Wrong Checkout

Description and use

Testing APX changes in a worktree can lead to false negatives because the daemon runs from the main checkout. Verifying the daemon’s checkout, restarting from the main checkout, checking health and logs, then exercising the real path eliminates stale code issues.

Problem

Testing APX changes in a worktree can lead to false negatives because the daemon runs from the main checkout, not the worktree, causing developers to waste time debugging stale code.

Outcome

By ensuring the daemon runs from the main checkout and verifying a fresh restart, developers avoid false negatives and reduce debugging time.

Workflow

• Patch code in a worktree
• Run unit tests in the worktree
• Check which checkout the daemon is running from using ps -o command -p $(pgrep -f 'src/host/daemon/index.js' | head -1)
• Restart the daemon from the main checkout with apx restart
• Verify the restart with curl -s 127.0.0.1:7430/api/health and apx daemon logs --tail 30
• Exercise the real code path (e.g., apx exec, API call, or UI interaction)

Evidence

The daemon is the product. The CLI, the web panel, Telegram, and the other surfaces all talk to that one long-running process.

Source

Restarting from the wrong directory is how I end up testing stale code while feeling productive.

Source

Only after that do I exercise the real path I changed.

Source