open-webui/computer

Fork 0

mirror of https://github.com/open-webui/computer.git synced 2026-11-05 01:17:24 +00:00

[GH-ISSUE #311] bug: Claude adapter workspace command permissions ineffective until settings file is passed explicitly #224

New issue

Open

opened 2026-10-18 14:03:56 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:03:56 +00:00

Owner

Originally created by @mdefehr on GitHub (Oct 6, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/311

Environment

cptr 0.9.21
Windows 11, Python 3.13
claude-agent-sdk 0.2.163
Claude CLI 2.1.289
cptr chat approval mode: Auto (adapter launches acceptEdits)
Headless cptr launched by Windows Task Scheduler
Workspace contains .claude/settings.json with explicit shell-command allow/deny rules

Summary

Workspace shell-command permissions are not being applied as expected in the Claude adapter:
commands explicitly allowed in .claude/settings.json still return "This command requires
approval", with no configured approval callback to resolve the request. Explicitly passing
the workspace settings file through ClaudeAgentOptions.settings resolves the tested cases.

This report concerns permission-policy loading and approval handling, rather than Git
functionality. Git commands provided the reproducible examples below. The broader effect
on other shell commands is suspected but has not been independently tested; we are not
claiming that every permission rule or tool type is affected.

Observed behavior

Plain git fetch --dry-run and git add -A return "This command requires approval" even
though the workspace settings include Bash(git fetch:) and Bash(git add:).
Read-only git status runs. There is no user-level permissions block or discovered local
settings override. Restarting cptr and the VM did not resolve the issue.

This was observed in a resumed Claude session. A clean new-session reproduction has not
been tested; maintainers may want to compare resumed and new sessions.

Expected behavior

Commands matching the workspace allow rules should execute, and commands matching deny
rules should be denied. Unmatched commands should have clearly defined approval behavior.

Experiments and results

Added setting_sources=["user", "project", "local"] to ClaudeAgentOptions.
Confirmed the fresh Claude process received --setting-sources=user,project,local.
Fetch and add still required approval.
Retained that option and explicitly passed the workspace settings file using the SDK's
settings option. After deployment/restart, the same resumed Claude session reported:
- git fetch --dry-run: executed successfully.
- git add -A: executed successfully.
- git clean -nd: explicitly denied (non-destructive dry run; no files removed).

No force-push or destructive reset was attempted. Denial was verified for git clean -nd;
other denied Git verbs were not independently exercised.

Working local patch

File: cptr/utils/agents/claude_code.py, run_claude_code_agent.
The tested patch adds setting_sources to options_kwargs:

"setting_sources": ["user", "project", "local"],

and adds conditional explicit settings delivery after assigning cwd:

if workspace:
    options_kwargs["cwd"] = workspace
    workspace_settings = os.path.join(workspace, ".claude", "settings.json")
    if os.path.isfile(workspace_settings):
        options_kwargs["settings"] = workspace_settings

os is already imported. Permission mode and callbacks were unchanged.
Only the combination was tested successfully; explicit settings without setting_sources
has not been tested independently.

Interpretation and requested investigation

Explicit settings delivery resolves this installation's symptoms, but the precise reason
ordinary project-settings discovery did not apply the rules remains unproven. The installed
SDK documents unset setting_sources as loading all sources, so we are not claiming omission
of that field universally disables filesystem settings, or that the SDK is conclusively
free of defects.

Please investigate workspace settings discovery/validation/trust and resumed-session behavior
in the Claude adapter. If explicit settings delivery is the intended fix, consider ancestor
project settings and precedence: the SDK settings option uses the flag settings layer, so
promoting a project file there may change intended user/project/local precedence.

Separate adapter observations

The adapter derives permission mode from the chat setting and does not read the profile's
saved permission_mode. Please clarify whether this override is intentional.
It supplies no can_use_tool callback. Requests requiring confirmation have no configured
callback decision path. Interactive approval support is a separate improvement; an
always-allow callback was not needed for this local fix.

Official SDK permission documentation:
https://code.claude.com/docs/en/agent-sdk/permissions

Suggested public reproduction and scope checks

Use a disposable Git repository/workspace, configure Bash(git fetch:) and Bash(git add:)
as allow rules and Bash(git clean:*) as a deny rule, and compare original vs patched adapter
behavior in both fresh and resumed sessions. Use clean -nd only to exercise the deny rule.
Do not include tokens, private repository URLs, full chat transcripts, or personal config
in the report. The observations above came from an existing workspace, not yet from this
minimal public reproduction.

To establish the scope beyond Git, also compare harmless non-Git shell commands with explicit
allow and deny rules in a disposable workspace. Check shell-command rule matching separately
from Read/Edit tool permissions; the current evidence does not establish a failure in those
other tool types. No blanket permission bypass or auto-approving callback was used in the
successful local patch.

Originally created by @mdefehr on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/311 ## Environment - cptr 0.9.21 - Windows 11, Python 3.13 - claude-agent-sdk 0.2.163 - Claude CLI 2.1.289 - cptr chat approval mode: Auto (adapter launches acceptEdits) - Headless cptr launched by Windows Task Scheduler - Workspace contains .claude/settings.json with explicit shell-command allow/deny rules ## Summary Workspace shell-command permissions are not being applied as expected in the Claude adapter: commands explicitly allowed in .claude/settings.json still return "This command requires approval", with no configured approval callback to resolve the request. Explicitly passing the workspace settings file through ClaudeAgentOptions.settings resolves the tested cases. This report concerns permission-policy loading and approval handling, rather than Git functionality. Git commands provided the reproducible examples below. The broader effect on other shell commands is suspected but has not been independently tested; we are not claiming that every permission rule or tool type is affected. ## Observed behavior Plain git fetch --dry-run and git add -A return "This command requires approval" even though the workspace settings include Bash(git fetch:*) and Bash(git add:*). Read-only git status runs. There is no user-level permissions block or discovered local settings override. Restarting cptr and the VM did not resolve the issue. This was observed in a resumed Claude session. A clean new-session reproduction has not been tested; maintainers may want to compare resumed and new sessions. ## Expected behavior Commands matching the workspace allow rules should execute, and commands matching deny rules should be denied. Unmatched commands should have clearly defined approval behavior. ## Experiments and results 1. Added setting_sources=["user", "project", "local"] to ClaudeAgentOptions. Confirmed the fresh Claude process received --setting-sources=user,project,local. Fetch and add still required approval. 2. Retained that option and explicitly passed the workspace settings file using the SDK's settings option. After deployment/restart, the same resumed Claude session reported: - git fetch --dry-run: executed successfully. - git add -A: executed successfully. - git clean -nd: explicitly denied (non-destructive dry run; no files removed). No force-push or destructive reset was attempted. Denial was verified for git clean -nd; other denied Git verbs were not independently exercised. ## Working local patch File: cptr/utils/agents/claude_code.py, run_claude_code_agent. The tested patch adds setting_sources to options_kwargs: ```python "setting_sources": ["user", "project", "local"], ``` and adds conditional explicit settings delivery after assigning cwd: ```python if workspace: options_kwargs["cwd"] = workspace workspace_settings = os.path.join(workspace, ".claude", "settings.json") if os.path.isfile(workspace_settings): options_kwargs["settings"] = workspace_settings ``` os is already imported. Permission mode and callbacks were unchanged. Only the combination was tested successfully; explicit settings without setting_sources has not been tested independently. ## Interpretation and requested investigation Explicit settings delivery resolves this installation's symptoms, but the precise reason ordinary project-settings discovery did not apply the rules remains unproven. The installed SDK documents unset setting_sources as loading all sources, so we are not claiming omission of that field universally disables filesystem settings, or that the SDK is conclusively free of defects. Please investigate workspace settings discovery/validation/trust and resumed-session behavior in the Claude adapter. If explicit settings delivery is the intended fix, consider ancestor project settings and precedence: the SDK settings option uses the flag settings layer, so promoting a project file there may change intended user/project/local precedence. ## Separate adapter observations - The adapter derives permission mode from the chat setting and does not read the profile's saved permission_mode. Please clarify whether this override is intentional. - It supplies no can_use_tool callback. Requests requiring confirmation have no configured callback decision path. Interactive approval support is a separate improvement; an always-allow callback was not needed for this local fix. Official SDK permission documentation: https://code.claude.com/docs/en/agent-sdk/permissions ## Suggested public reproduction and scope checks Use a disposable Git repository/workspace, configure Bash(git fetch:*) and Bash(git add:*) as allow rules and Bash(git clean:*) as a deny rule, and compare original vs patched adapter behavior in both fresh and resumed sessions. Use clean -nd only to exercise the deny rule. Do not include tokens, private repository URLs, full chat transcripts, or personal config in the report. The observations above came from an existing workspace, not yet from this minimal public reproduction. To establish the scope beyond Git, also compare harmless non-Git shell commands with explicit allow and deny rules in a disposable workspace. Check shell-command rule matching separately from Read/Edit tool permissions; the current evidence does not establish a failure in those other tool types. No blanket permission bypass or auto-approving callback was used in the successful local patch.

No labels

enhancement

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/computer#224

No description provided.

Rows
Columns