Decouple Data Machine-specific plumbing from the agent-task sandbox boot script

[chubes4]

Problem

The agent-task sandbox boot script generated by packages/cli/src/agent-code.ts (both agentSandboxRunCode and agentRuntimeProbeCode) hardcodes Data Machine-specific plumbing into wp-codebox's generic substrate. wp-codebox is meant to be a vendor-neutral WordPress execution substrate, but its boot path embeds one runtime's internals.

The Data Machine coupling (vendor-specific, ~20 lines)

• DATAMACHINE_WORKSPACE_PATH define + directory creation (agent-code.ts ~107-115, ~508-516)
• add_filter('datamachine_code_remote_workspace_backend_should_handle', '__return_false', 100) (~118, ~519)
• wp_get_ability('datamachine/workspace-adopt') workspace adoption loop (~123-150)
• DataMachine\Abilities\PermissionHelper::run_as_authenticated(...) wrappers (~147, ~332)

A consumer who does not use Data Machine still gets this Data-Machine plumbing baked into every sandbox boot.

Not in scope: a pluggable multi-runtime adapter

Agents API is the only WordPress agent runtime, and it is headed for WordPress core. So the agent-loop pieces the boot depends on are becoming standard WordPress, not vendor-specific, and there is no second runtime to justify an adapter abstraction (avoid abstracting on n=1):

• agents/chat (the loop entry), wp_get_agent, WP_Agent_Execution_Principal, the agents_chat_runtime_principal_permission filter, and the agent registry are core-bound. Depending on these is fine; as Agents API lands in core they become core API calls.

The issue is specifically the Data Machine Code plumbing, which is not going to core and should not live in wp-codebox.

Proposed direction: mounted components self-configure

The boot already fires generic WordPress lifecycle hooks after mounting components:

do_action('plugins_loaded');
do_action('init');
do_action('wp_abilities_api_categories_init');
do_action('wp_abilities_api_init');

Data Machine Code is mounted as a mu-plugin before these fire, so it can register its own sandbox boot behavior (workspace path, remote-backend filter, workspace adoption) on those hooks instead of wp-codebox emitting Data-Machine PHP. Then:

• wp-codebox's boot script contains no Data Machine symbol.
• Data Machine remains the runtime in use; it simply owns its own boot.
• A future non-Data-Machine runtime just does not ship those hooks — no N-runtime adapter framework required. The seam is "mounted components self-configure," which already exists.

Suggested shape

1. Move the DATAMACHINE_WORKSPACE_PATH / remote-backend-filter / workspace-adopt / PermissionHelper logic out of agent-code.ts into Data Machine Code, hooked on plugins_loaded/init.
2. Keep the generic boot in wp-codebox: mount components, fire lifecycle hooks, resolve the loop ability (default agents/chat, overridable via runtime_task.ability), execute, capture diffs.
3. Optionally provide a small documented contract for "what a mounted runtime component may rely on at boot" (lifecycle hook order, workspace root convention) so component-side self-configuration is well-defined.

Context

Surfaced while building headless WordPress agent cooking on a Lab runner (see Extra-Chill/homeboy-extensions wordpress/docs/LAB_COOKING.md). The flow works today with Data Machine; this is about keeping wp-codebox vendor-neutral so it is not structurally tied to Data Machine.

AI assistance

• AI assistance: Yes
• Tool(s): Claude Code (Opus 4.7)
• Used for: Classified the boot-script coupling (core-bound Agents API vs vendor Data Machine Code) and drafted this decoupling direction; Chris set the architectural intent (prevent Data Machine coupling without over-abstracting for runtimes that will not exist).