fix(settings): clarify sandbox modes and improve blocked-command hint (#270)#274
Open
whitelonng wants to merge 1 commit into
Open
fix(settings): clarify sandbox modes and improve blocked-command hint (#270)#274whitelonng wants to merge 1 commit into
whitelonng wants to merge 1 commit into
Conversation
…KunAgent#270) Users were confused by the file-access modes because each option only showed a 4-5 word label with no explanation of what it allows or blocks (notably that shell commands are blocked under workspace-write). When bash was actually blocked the raw backend error string was shown verbatim with no localization or guidance. - Add per-mode descriptions (en/zh) to settings.json and surface the one matching the currently selected mode in the sandbox SettingRow, so the constraints update live as the user switches modes. - Add a localized hint above the raw error in the tool error card when the message looks like a sandbox block (matched via the stable 'is blocked' substring), pointing users to Settings to raise the access level. The original error text is preserved below for debugging. Frontend-only; no kun runtime changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #270 (UX). When a shell command is blocked by the
workspace-writesandbox, the raw backend error string (tool bash is blocked because workspace-write cannot sandbox host shell commands) is shown verbatim with no localization and no guidance on how to resolve it. Users in the issue comments were also confused about the differences between the four file-access modes.This PR is a frontend-only UX fix (no kun runtime changes):
1. Per-mode descriptions in Settings
Previously each sandbox option in Settings showed only a 4–5 word label (
Can edit workspace,Can only read files, …) with a single generic description that didn't explain what each mode actually allows or blocks — in particular, that shell commands are blocked underworkspace-write.Added four
sandboxXxxDescstrings (en/zh) and made theSettingRowdescription update live to match the currently selected mode, so users see the concrete constraints (e.g. "Read and write files inside the workspace. Shell commands are blocked.") right under the dropdown.2. Localized hint when a tool is blocked by the sandbox
In
message-timeline-process.tsx, when a tool error message looks like a sandbox block (matched via the stableis blockedsubstring shared by all three backend sandbox error messages insandbox-policy.ts), a localized one-line hint is shown above the raw error text, pointing the user to Settings → File access range → Can access all files. The original English error is preserved below for debugging.Why frontend-only / string matching
ToolBlockcarries the error as a plain text string indetail— there's no structured error code field on the block (thesandbox_command_blockedcode exists in the backend but isn't surfaced to the frontend tool block). Changing the kun runtime to propagate a structured code is out of scope for this UX fix and would couple the change across both layers.is blockedis a stable public substring present in all three sandbox error messages (sandbox_read_only,sandbox_write_blocked,sandbox_command_blocked), so matching risk is low.Verification
npm run typecheckpassesnpm run lint— 0 errors (9 pre-existing warnings unchanged)npx vitest run src/renderer/src/components— 257/257 passed