What task are you trying to do?

When PawWork wants to do something outside the current working directory, such as read a sibling project, run a one-off bash command, fetch a URL, or edit a config file in my home directory, I want to decide based on what kind of action and which path, not be forced into a binary "everything inside the workspace is allowed, everything outside is blocked" rule.

What do you do today?

The user-visible behavior today feels binary: inside the working directory PawWork acts freely; outside the working directory it is blocked or constantly asks. In practice the workflow forces me to either restart the session in a parent directory just to read one neighboring file, approve every individual prompt one by one, or accept that PawWork cannot help with cross-project tasks at all. None of those match how I actually work. Most real tasks touch the workspace heavily but also need occasional access to ~/.config, ~/Downloads, neighboring repos, or system tools.

What would a good result look like?

I can describe permission in terms I think in: tool type, path scope, and decision. Examples:

• Let PawWork read anywhere under ~/projects/, but always ask before editing outside the current workspace.
• Auto-approve git status and ls style read-only bash, ask for everything else.
• Always deny destructive actions outside selected directories.

The Settings UI shows me what rules are active and lets me edit them in place, instead of forcing me to hand-edit config.json. Defaults out of the box should be sensible for a non-technical user: restrictive enough that nothing surprising happens, permissive enough that common workflows do not require constant approval.

Priority triage

P1.

Permissions are one of the main trust surfaces in PawWork. The engine already has granular rules, but users cannot see or adjust them through the product. That makes common cross-project work feel blocked or noisy, and it makes high-risk actions harder to reason about. This should sit above general Settings polish because it affects whether users can safely let PawWork act.

Which audience does this matter to most?

Both

Extra context

Important context: the underlying schema already supports granular permission rules. This issue is mostly about defaults plus GUI exposure, not a new permission engine.

• packages/opencode/src/config/permission.ts already defines per-tool rules such as read, edit, glob, grep, list, bash, agent, external_directory, todowrite, question, webfetch, websearch, lsp, doom_loop, and skill. Each can take an action or a wildcard pattern map.
• packages/opencode/src/permission/evaluate.ts already evaluates rules with wildcard matching.
• What is missing is the product surface:
  • the default ruleset shipped with PawWork is coarse enough that users perceive the system as binary,
  • Settings does not expose a way to view or edit these rules,
  • onboarding does not explain that permission is configurable.

Loosely related: #238 is the sibling effort for exposing instruction customization. Both share a common product gap: PawWork has powerful customization underneath but does not surface it.

Acceptance criteria

• Users can view the active permission rules in Settings without opening a config file.
• Users can edit the common rule shapes safely: tool type, path scope, and ask/allow/deny decision.
• Defaults are reviewed for non-technical users and documented in the PR body.
• The UI makes risky rules visually clear before saving.
• Existing config files keep working.
• The engine-level wildcard behavior is covered by focused tests if touched.

Verification

• Add focused tests for any permission default or serialization change.
• Add user-path coverage for viewing and saving a simple permission rule in Settings where practical.
• Manually verify the Settings flow in Electron via bun run dev:desktop.