fix(runtime): surface sandbox-blocked tool failures

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.

[YayoiNanoka]

Summary

• Preserve structured sandbox-denial metadata for command and filesystem-worker failures instead of collapsing them into generic tool errors.
• Present sandbox-blocked tool rows and output panels with dedicated warning copy, while suppressing the duplicate generic failed-turn banner.
• Keep strict RuntimeEvent persistence lossless by omitting absent context-budget counters, and use bundle-safe Node builtin imports required by the desktop build.

Verification

• npm run build:test
• npm run typecheck
• Focused Core, Runtime, UI, and Desktop tests: 294 passed
• Biome check for all 29 changed TypeScript files
• npm run test:checks -w @maka/desktop (console, accessibility, and copy checks)
• Desktop development app starts successfully

Review focus

• The new status is diagnostic only: it does not automatically retry or elevate a command.
• Ordinary filesystem permission errors remain generic failures; only explicit or likely sandbox denials receive the sandbox-specific presentation.
• Partial command effects remain visible, and the copy asks users to inspect output and workspace state before retrying.

中文说明

改动内容

• 为命令和 filesystem worker 的 sandbox denial 保留结构化元数据，不再全部折叠成普通工具失败。
• 前端使用“可能被沙箱阻止”的独立状态和警告样式，并避免同时显示重复的整轮“未知错误”提示。
• 修复 context-budget 可选计数字段写入 undefined 后导致 RuntimeEvent 无法持久化的问题。
• 调整 Node 内置模块导入方式，保证 Desktop 构建和启动兼容。

行为边界

“可能被沙箱阻止”只是一项诊断结果，不会自动提权或重试。Agent 仍需发起新的、显式声明权限的工具调用，并经过既有审批流程。普通运行失败不会被错误标记为 sandbox denial。

验证结果

构建、全仓类型检查、Biome、Desktop 静态检查，以及 294 个相关自动化测试均已通过。

[Astro-Han]

Reviewed 21d4679803. Three P2 issues remain:

• [P2] filesystem-worker/operations.ts calls isLikelySandboxDenial with sandboxed: true even when the worker is running with sandboxType: none. Under bypass or another unrestricted profile, an OS ACL or TCC error containing Operation not permitted is persisted and shown as a sandbox denial. Only emit this signal when the client actually used macos-seatbelt or linux, and cover the unrestricted case.

• [P2] Background shell_run failures do not get the new row treatment. overlayShellRunUpdates() replaces the result but keeps the original Bash item status as completed; isSandboxDeniedTool() then rejects it because the item is not errored. A failed background command with sandboxDenial therefore looks completed while collapsed. Derive the presentation from the structured result, or update the projected status, and test the overlay-to-summary path.

• [P2] isSandboxOnlyToolFailure() also suppresses the turn failure banner when errorClass is missing or unknown. That does not establish that the turn failed because of the sandboxed tool. A sandbox-denied tool followed by an unrelated unknown provider or transport failure loses both failure labels. Limit suppression to explicit tool/sandbox error classes and keep unknown failures visible.

The schema and propagation seam otherwise look sound, and CI is green.

[Astro-Han]

Approved at 21d4679803. The three P2 findings in the earlier comment are still worth fixing, but none is a P0/P1 or a merge blocker. CI is green.