migrate live extrachill.com off RUN_AS_ROOT to the opencode service user (durable fix for #93 + #198 root-ownership cascade)

[chubes4]

Summary

This is the concrete, live-VPS follow-through for #93 (and the durable fix that makes #198 moot): migrate the running extrachill.com install off RUN_AS_ROOT (kimaki.service User=root) to the dedicated opencode service user that is already provisioned and already a member of the www-data group.

Running the agent runtime as root is the root cause of two distinct, recurring breakages:

• RUN_AS_ROOT path leads to root-owned files cascading through site (cause: kimaki.service runs as root, every wp-cli inherits root, every file written is root-owned) #93 — every file the agent/wp-cli writes lands root:root, so www-data WordPress auto-update fails with copy_failed_*.
• fix: agent CLI binary registered under /root is unreachable by www-data WP-cron, causing recurring datamachine_code_cli_dispatch_spawn_failed #198 — the kimaki binary + data dir live under /root (0700), unreachable by the www-data WP-cron dispatch path, so scheduled agents/dispatch-message flows fail with datamachine_code_cli_dispatch_spawn_failed.

Both vanish if the runtime runs as opencode (group www-data) with state in a www-data-traversable location. The installer already defines this path (lib/detect.sh else-branch) but this box was installed with RUN_AS_ROOT=true and never migrated.

Current live state (extrachill.com, verified)

The opencode user already exists and is correctly grouped — the migration is half-done and inconsistent:

$ id opencode
uid=1000(opencode) gid=1000(opencode) groups=1000(opencode),4(adm),33(www-data)   # already in www-data ✓

$ grep -E '^User=|HOME=|--data-dir' /etc/systemd/system/kimaki.service
User=root                                  # <-- still root (the trap)
Environment=HOME=/home/opencode            # <-- but HOME points at opencode (!)
ExecStart=/root/.kimaki/bin/kimaki --data-dir /root/.kimaki ...   # <-- and data-dir is /root

$ ls -ld /home/opencode /home/opencode/.kimaki
drwxr-x--- opencode opencode  /home/opencode            # 0750
drwxr-xr-x opencode opencode  /home/opencode/.kimaki    # already exists, opencode-owned

So the unit is a Frankenstein: runs as root, HOME says opencode, data-dir says /root. The opencode user, its home, and /home/opencode/.kimaki are all already provisioned — only User= and the --data-dir/binary path are wrong.

Live cascade damage from running as root (#93 evidence)

$ find wp-content     -user root | wc -l    # 191
$ find wp-content/uploads -user root | wc -l    # 147
$ find wp-admin wp-includes -user root | wc -l    #   0   (core is clean — good)

Sample root-owned files (must be re-chowned as part of migration):

wp-content/mu-plugins/wp-coding-agents-channels.php
wp-content/mu-plugins/wp-coding-agents-runtimes.php
wp-content/uploads/sites/7/datamachine-files/pipeline-32/flow-732
wp-content/uploads/2026/05/IMG_1655-scaled-1-1196x1536.jpg
wp-content/uploads/sites/12/backup/...

Critical gotcha the migration MUST handle (else it just re-creates #198)

/home/opencode is mode 0750, so www-data cannot traverse it:

$ sudo -u www-data test -x /home/opencode && echo ok || echo BLOCKED
BLOCKED
$ sudo -u www-data test -r /home/opencode/.kimaki/bin/kimaki && echo ok || echo BLOCKED
BLOCKED

This means a naive User=root → User=opencode flip that registers /home/opencode/.kimaki/bin/kimaki as the CLI-dispatch command would reproduce exactly the #198 spawn failure at a new path — www-data still can't traverse /home/opencode (0750). The migration is only complete if the dispatch command resolves to a system-PATH binary every relevant user can reach (/usr/bin/kimaki, the npm-global symlink — already present on this host and confirmed www-data-executable in #198).

This is why #198 option (a) and this migration are complementary, not duplicate: (a) ensures the registered command is system-reachable regardless of service user; this migration removes the root-write cascade. Land (a) first, then this.

Proposed migration steps (live VPS)

1. Pre-flight: confirm opencode ∈ www-data (done), /home/opencode + /home/opencode/.kimaki exist (done). Stop kimaki.service.
2. Rewrite the unit to the canonical non-root template the installer already knows how to emit:
   • User=opencode
   • Environment=HOME=/home/opencode
   • --data-dir /home/opencode/.kimaki
   • ExecStart binary → /usr/bin/kimaki (or which kimaki resolved to the system prefix, not $SERVICE_HOME/.kimaki/bin)
   • add UMask=0002 so opencode's writes are group-writable by www-data (ties in setup: enforce UMask=0002 on php-fpm + kimaki services so coding-agent writes stay group-writable (WP auto-update keeps failing on stamped 0644 files) #125).
3. Re-register the CLI channel so the dispatch command is /usr/bin/kimaki (the fix: agent CLI binary registered under /root is unreachable by www-data WP-cron, causing recurring datamachine_code_cli_dispatch_spawn_failed #198 (a) resolver fix; verify the mu-plugin block updates).
4. Remediate existing root-owned files (one-time):
   • chown -R www-data:www-data wp-content/uploads (and the 191 wp-content + 147 uploads root-owned files), or more surgically find wp-content -user root -exec chown www-data:www-data {} +.
   • confirm the two wp-coding-agents-*.php mu-plugins end up www-data-readable (they are, at 0644 per fix(lib): mu-plugins written by lib/cli-channel.sh and lib/runtime-signature.sh land as 0600, breaking PHP-FPM read #133, but should be re-chowned for hygiene).
5. Confirm wp no longer needs --allow-root in the agent context, and that data-machine-code's datamachine_code_resolve_wp_cli_cmd() stops baking --allow-root into AGENTS.md (it keys on posix_geteuid() === 0). Running as opencode makes that detection correctly drop --allow-root, ending the loop described in RUN_AS_ROOT path leads to root-owned files cascading through site (cause: kimaki.service runs as root, every wp-cli inherits root, every file written is root-owned) #93 step 2.
6. Verify:
   • systemctl status kimaki → active as opencode.
   • Manually run flow 4 (EC Agent Progress Ping) AND wait for a scheduled fire — both should complete (previously only manual-as-root worked, see fix: agent CLI binary registered under /root is unreachable by www-data WP-cron, causing recurring datamachine_code_cli_dispatch_spawn_failed #198).
   • sudo -u www-data /usr/bin/kimaki --version works (already confirmed).
   • New agent file writes land opencode:opencode or www-data-group-writable, not root:root.
   • A subsequent wp plugin update / WP auto-update no longer hits copy_failed_*.

Installer-side durability (so this doesn't regress)

The live remediation above is one-time, but the installer should stop offering/defaulting to RUN_AS_ROOT on VPS, or at minimum:

• lib/detect.sh: make the opencode non-root branch the VPS default; treat RUN_AS_ROOT=true as an explicit opt-in footgun with a loud warning (it currently triggers whenever the elif is reached).
• ensure _kimaki_find_native_binary / _kimaki_register_cli_channel (fix: agent CLI binary registered under /root is unreachable by www-data WP-cron, causing recurring datamachine_code_cli_dispatch_spawn_failed #198 (a)) never register a path under a 0700/0750 home — pick a system-prefix binary.
• emit UMask=0002 on the kimaki + php-fpm units (setup: enforce UMask=0002 on php-fpm + kimaki services so coding-agent writes stay group-writable (WP auto-update keeps failing on stamped 0644 files) #125).
• lib/infrastructure.sh already does chown -R www-data:www-data $SITE_PATH and useradd -G www-data opencode for the non-root path — that's the correct durable baseline; the bug is only that this VPS took the root branch.

Why NOT "make root safe instead"

Keeping User=root and trying to make it WordPress-safe requires chmod 0701 /root (defeats /root privacy), UMask=0002 everywhere, and forcing wp/agent writes to drop to www-data — strictly worse than running as the opencode user that is already built and already group-aligned. The platform's own design intent (the lib/detect.sh default branch) is a dedicated non-root service user. This issue just makes the live box match that intent.

Cross-references

• RUN_AS_ROOT path leads to root-owned files cascading through site (cause: kimaki.service runs as root, every wp-cli inherits root, every file written is root-owned) #93 — systemic parent (root-owned file cascade → WP auto-update breakage). This is its concrete live remediation.
• fix: agent CLI binary registered under /root is unreachable by www-data WP-cron, causing recurring datamachine_code_cli_dispatch_spawn_failed #198 — CLI dispatch spawn failure; option (a) is the complementary binary-path fix that must land alongside/before this.
• setup: enforce UMask=0002 on php-fpm + kimaki services so coding-agent writes stay group-writable (WP auto-update keeps failing on stamped 0644 files) #125 — UMask=0002 on php-fpm + kimaki services (folded into step 2/installer durability).

[chubes4]

Cross-reference: #327 frames the agent's server capability as a second axis alongside the file-write axis in lib/source-policy.sh, and lands on the non-root service user as the only lever that actually contains rather than advises.

That makes this migration wanted for two independent reasons — the root-ownership cascade tracked here, and containment for managed installs where the site owner cannot evaluate the risk. Same change, two motivations.