Greptile Summary

Adds effective-mounts introspection to openclaw sandbox explain: sandbox.mounts now appears in JSON output, and a matching "Effective mounts:" block is printed in text mode. The implementation delegates to the existing buildSandboxFsMounts helper and threads the result through the existing payload object unchanged. All findings are P2 style suggestions.

Confidence Score: 5/5

Safe to merge; the change is additive and all remaining findings are P2.

No logic errors or regressions introduced. The new code correctly reuses buildSandboxFsMounts and passes the right context fields. Both JSON and text paths work as expected. Remaining comments are style suggestions (line length, missing text-output test).

No files require special attention.

This is a comment left during a code review.
Path: src/commands/sandbox-explain.ts
Line: 323-329

Comment:
**Long single-line mount entry format**

Each mount is rendered as a single line with four key-value pairs. For agents with real host paths this can exceed 180+ characters, making it hard to scan at a glance. Consider a multi-line format per mount to stay within comfortable terminal width:

```suggestion
  lines.push(heading("Effective mounts:"));
  for (const mount of payload.sandbox.mounts) {
    lines.push(`  - ${key("source:")} ${value(mount.source)}`);
    lines.push(`    ${key("hostRoot:")} ${value(mount.hostRoot)}`);
    lines.push(`    ${key("containerRoot:")} ${value(mount.containerRoot)}`);
    lines.push(`    ${key("writable:")} ${bool(mount.writable)}`);
  }
```

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

---

This is a comment left during a code review.
Path: src/commands/sandbox-explain.test.ts
Line: 99-135

Comment:
**Text output path has no test coverage**

All three tests call `sandboxExplainCommand` with `json: true`. The new "Effective mounts:" text rendering path (lines 322–330 of the source) has no coverage. A simple test with `json: false` that checks `logs.join("")` contains `"Effective mounts:"` and at least one `"source:"` token would guard against any future regression in the text format.

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

_{Reviews (1): Last reviewed commit: "CLI: show effective sandbox mounts" | Re-trigger Greptile}

Addressed review notes:

• Mounts now only render when sessionIsSandboxed is true; otherwise JSON returns an empty array and text prints a (none) runtime is direct hint to avoid misleading users.
• Workspace root is normalized via resolveUserPath (including shared scope) to match runtime behavior.
• Text output for mounts is now multi-line per mount for easier scanning.
• Added a small json:false test that asserts the Effective mounts: section renders.

Follow-up: addressed the agent-workspace override note.

• sandbox explain now derives agentWorkspaceDir via resolveAgentWorkspaceDir(cfg, agentId) to match runtime workspace resolution (including agents.list[].workspace and agents.defaults.workspace).
• Added a test that sets an agent-specific workspace override and asserts the source: agent mount reports the overridden hostRoot.

Codex automated review: keeping this open.

Current main still lacks the requested sandbox.mounts JSON field and Effective mounts: text section. The linked issue #62988 is closed as superseded by this PR, so this PR remains the active implementation candidate, but the current diff still needs maintainer cleanup because mount output is security-boundary introspection.

Best possible solution:

Keep this PR open as the active implementation candidate. Revise it to compute sandboxed status through resolveSandboxRuntimeStatus, derive effective mounts from the selected sandbox backend or a shared backend-aware mount contract, keep both JSON and text output, add focused coverage for JSON, text, Docker binds, direct runtime, session aliases, agent workspace overrides, and remote roots, and remove unrelated test-file churn before maintainer review.

What I checked:

• Current main JSON payload has no mounts field: sandboxExplainCommand builds payload.sandbox with mode, scope, workspaceAccess, workspaceRoot, sessionIsSandboxed, and tools only; there is no mounts property. (src/commands/sandbox-explain.ts:241, f0b327cf686e)
• Current main text output has no Effective mounts section: The renderer prints Effective sandbox:, then Sandbox tool policy:, Elevated:, and Fix-it:. A repository search for Effective mounts and sandbox.mounts returned no matches in source, tests, or docs. (src/commands/sandbox-explain.ts:286, f0b327cf686e)
• Current sandbox explain tests do not cover mounts: The current tests assert the existing JSON shape, fix-it keys, and sandbox tool policy behavior, but do not assert sandbox.mounts, bind mount reporting, or text rendering for Effective mounts:. (src/commands/sandbox-explain.test.ts:16, f0b327cf686e)
• Existing mount helper makes the feature plausible: buildSandboxFsMounts already returns deterministic workspace, agent, and bind mount entries with hostRoot, containerRoot, writable, and source, matching the requested data model for Docker-style mounts. (src/agents/sandbox/fs-paths.ts:61, f0b327cf686e)
• Canonical sandbox status path exists separately: resolveSandboxRuntimeStatus canonicalizes main/global aliases before deciding whether a session is sandboxed. The provided PR discussion and review comments point out that the PR-local mount emission still depends on the raw sandbox explain session comparison path, which can misreport mounts for direct sessions. (src/agents/sandbox/runtime-status.ts:51, f0b327cf686e)
• Remote backends have different effective roots: The remote filesystem bridge derives effective container roots from remoteWorkspaceDir and remoteAgentWorkspaceDir, while the PR diff builds mount output through the Docker-style buildSandboxFsMounts path. That can misstate effective roots for SSH/OpenShell-style backends. (src/agents/sandbox/remote-fs-bridge.ts:241, f0b327cf686e)

Remaining risk / open question:

• Merging the current diff can report mounts for sessions that canonical runtime status would treat as direct, especially main/global aliases.
• Merging the current diff can report Docker-style container roots for SSH/OpenShell-style backends where effective roots come from remote runtime paths.
• Mount metadata is additive output, not code execution, but it is security-relevant because users may rely on it to understand filesystem exposure.
• The PR includes unrelated import-order churn in test/image-generation.runtime.live.test.ts, which should be removed before maintainer review.

Codex Review notes: model gpt-5.5, reasoning high; reviewed against f0b327cf686e.