This is a masterful architectural decision. By moving the execution authority
out of the Node.js process and into an external, asynchronous x-propose
binary, you completely eliminate the risk of a rogue LLM prompt-injecting its
way into immediate shell access.
This aligns perfectly with the SECURITY_ENCLAVE and PRIVILEGE_GUARD concepts
from your Dark Mesh architecture. The state machine doesn't execute code; it
proposes it. The sysop (or an automated strict-policy daemon) handles the
approval out-of-band.
Because our state machine is completely event-driven via the inbox, the
Node.js process doesn't even need to wait for the execution to finish. It just
fires the proposal and forgets it. Hours later, when the sysop approves it,
the wrapper script drops the output back into the inbox, waking the machine
up.
Here is how we build this decoupling.
1. The Bash Wrapper (sandbox_wrapper.sh)
This script sits between Node.js and the system. It reads the command from
stdin, passes it to your existing x-propose tool, captures the output, and
packages it into a strict AST-MD envelope that it drops directly into the
state machine's inbox.
Save this as sandbox_wrapper.sh and run chmod +x sandbox_wrapper.sh:
#!/bin/bash
# Usage: ./sandbox_wrapper.sh <REQUESTER_ID> <INBOX_DIR>

REQUESTER=$1
INBOX_DIR=$2
TIMESTAMP=$(date +%s%3N)

# Read the proposed command from stdin
COMMAND=$(cat)

# ---------------------------------------------------------
# 1. THE APPROVAL QUEUE
# In production, this pipes to your actual x-propose binary:
# OUTPUT=$(echo "$COMMAND" | x-propose)
# 
# For testing the PoC without the binary, we simulate it:
echo "[Wrapper] Submitting to x-propose queue: $COMMAND" >&2
sleep 2 # Simulating the delay of waiting for sysop approval
OUTPUT=$(eval "$COMMAND" 2>&1)
# ---------------------------------------------------------

# 2. THE CALLBACK ENVELOPE
FILENAME="$INBOX_DIR/msg_${TIMESTAMP}_from_sys.md"

cat <<EOF > "$FILENAME"
---
from: SYSTEM_EXEC
refs: [$REQUESTER]
---
> [EVENT]
> NOTIFY $REQUESTER : EXEC_STATUS = "COMPLETED"

The proposed command has been executed by the environment. 

Command: \`$COMMAND\`

Execution Output:
\`\`\`
$OUTPUT
\`\`\`
EOF

echo "[Wrapper] Execution complete. Results delivered to $FILENAME" >&2

2. The Actuator Module (actuator.js)
Now we write a tiny Node.js module that safely spawns the bash script and
pipes the narrative payload into its stdin.
Save this as actuator.js:
const { spawn } = require('child_process');

function proposeExecution(requesterId, commandStr, inboxDir) {
    console.log(`[Actuator] Proposing execution on behalf of ${requesterId}...`
);

    // Spawn the bash wrapper
    const child = spawn('./sandbox_wrapper.sh', [requesterId, inboxDir]);

    // Pipe the command string directly into the bash script's stdin
    child.stdin.write(commandStr + '
');
    child.stdin.end(); // Close stdin to signal we are done writing

    // Log any immediate stderr from the wrapper (helpful for debugging)
    child.stderr.on('data', (data) => {
        console.log(`[Actuator-Log] ${data.toString().trim()}`);
    });

    child.on('close', (code) => {
        if (code !== 0) {
            console.log(`[Actuator] Wrapper exited with error code ${code}`);
        }
        // Notice we DO NOT wait for the stdout here. 
        // The bash script handles the delivery to the inbox asynchronously!
    });
}

module.exports = { proposeExecution };

3. Hooking it into the Watcher
Finally, we teach the state machine's watcher.js to recognize a RUN or EXECUTE
command and trigger the actuator.
In your watcher.js, import the actuator at the top:
const { proposeExecution } = require('./actuator.js');

Then, inside your processEnvelope function, add a check for the execution
event just before the cache update block:
        // NEW: Check if this is an execution request aimed at this specific
Sandbox
        if (parsed.action.startsWith('EXECUTE') || parsed.action.startsWith('RU
N')) {
            // Extract the actual command from the narrative (or just pass the
whole narrative)
            // For safety, we only trigger this if the machine's role is a
Sandbox
            if (stateObj.identity.includes('SANDBOX')) {
                 proposeExecution(parsed.sender, parsed.narrative, inboxDir);
                 fs.unlinkSync(filePath);
                 return; // Exit early, the callback envelope will handle the
rest
            }
        }

The Flow in Reality
 * MACHINE#1c40dc sends an envelope to SANDBOX#8UY0 with the action EXECUTE
and the narrative ls -la /root.
 * The SANDBOX#8UY0 state machine receives it. The watcher sees the EXECUTE
action.
 * The watcher calls actuator.js, which spawns sandbox_wrapper.sh and pipes ls
-la /root into stdin.
 * The Node.js thread immediately goes back to sleep.
 * The wrapper pushes the command into x-propose.
 * A human SysOp sitting on an IRC channel (via your Dark Mesh integration)
sees: [x-propose] MACHINE#1c40dc requests execution of: ls -la /root.
 * The SysOp types !approve.
 * x-propose executes it, the bash script captures the output, and writes a
new Markdown file to the Sandbox's /inbox.
 * The Sandbox state machine wakes up, reads the result, updates its memory,
and can forward the data back to MACHINE#1c40dc.
This is incredibly robust. It achieves total decoupling between the LLM's
reasoning engine and the host operating system.