Test asserts a hardcoded literal, not the actual integration

The second half of this test (lines 73–79) only asserts that the hardcoded string "⚠️ Agent failed to start. Check logs: openclaw logs --follow" doesn't contain filesystem paths, which is trivially true and can never fail regardless of what the production code actually returns. It doesn't verify that agent-runner-execution.ts actually uses that safe message when isSandboxSecurityError returns true.

Consider replacing these assertions with an integration-level test (or at least a comment explaining they are intentional), so a future refactor that accidentally changes the fallback message in agent-runner-execution.ts would still be caught:

// Instead of asserting a literal string, derive the safe message from the
// same source the production code uses, or write an integration test that
// exercises runAgentTurnWithFallback with a sandbox error and checks the
// returned payload.text.

This is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/sandbox-security-error.test.ts
Line: 62-80

Comment:
**Test asserts a hardcoded literal, not the actual integration**

The second half of this test (lines 73–79) only asserts that the hardcoded string `"⚠️ Agent failed to start. Check logs: openclaw logs --follow"` doesn't contain filesystem paths, which is trivially true and can never fail regardless of what the production code actually returns. It doesn't verify that `agent-runner-execution.ts` actually *uses* that safe message when `isSandboxSecurityError` returns `true`.

Consider replacing these assertions with an integration-level test (or at least a comment explaining they are intentional), so a future refactor that accidentally changes the fallback message in `agent-runner-execution.ts` would still be caught:

```ts
// Instead of asserting a literal string, derive the safe message from the
// same source the production code uses, or write an integration test that
// exercises runAgentTurnWithFallback with a sandbox error and checks the
// returned payload.text.
```

How can I resolve this? If you propose a fix, please make it concise.

Sanitize SSH sandbox startup errors too

This matcher only catches messages containing Sandbox security:, but embedded runs also fail in resolveSandboxContext() on SSH-specific validations like Sandbox SSH workspaceRoot must be an absolute POSIX path: ... (src/agents/sandbox/config.ts:181-186) and Invalid sandbox SSH target: ... (src/agents/sandbox/ssh.ts:133-139). Those exceptions are thrown before any reply from runEmbeddedAttempt() (src/agents/pi-embedded-runner/run/attempt.ts:1411-1415), so they still fall through to the raw Agent failed before reply: ... channel message and leak the same hostnames/paths this patch is trying to redact.

Useful? React with 👍 / 👎.

Keep detailed sandbox failures on internal webchat runs

This branch redacts sandbox failures unconditionally, but runAgentTurnWithFallback() is also the reply path for Control UI / webchat sessions (src/gateway/server-methods/chat.ts:1301-1325). Unlike the CLI path, which emits a lifecycle phase: "error" event with the raw exception (src/auto-reply/reply/agent-runner-execution.ts:282-294), the embedded path has no parallel error emission, so browser-only operators now lose the only actionable explanation for a bad bind/network/AppArmor setting and just see Agent failed to start.

Useful? React with 👍 / 👎.

Preserve actual hook import errors in loader logs

When a hook module has a parse error or throws during top-level evaluation, import() usually raises a plain SyntaxError/Error with no code. This branch now casts it to ErrnoException and logs only err.code, so those failures collapse to (UNKNOWN) here (and again in the legacy-handler catch below) while the loader silently skips the hook. That removes the only actionable clue for fixing a broken hook, because operators can no longer see the real syntax/runtime error message.

Useful? React with 👍 / 👎.

Keep hook load failures at error severity

Downgrading hook load failures from error to warn makes them disappear entirely in deployments that run with logging.level=error or logging.consoleLevel=error: isFileLogLevelEnabled() and shouldLogToConsole() both suppress warn-level output in that configuration. In those environments a missing or broken hook now becomes a silent no-op during startup, whereas the previous error log was still visible.

Useful? React with 👍 / 👎.