Track Claude Agent SDK support and upstream permission-hook blockers

[eharris128]

Summary

We previously attempted Claude Agent SDK / Claude Code integration in Progent on February 4, 2026:

• Add broken claude implementation, CI / CD testing & some other quality of life improvements progent#1

Janus main currently has no Claude adapter. Before adding one, we should track whether Anthropic's permission boundary is reliable enough for policy enforcement.

Why This Matters

Janus is meant to enforce at the tool-call boundary. If canUseTool / can_use_tool or Claude Code hooks can be skipped, timeout, or fail open, a Janus adapter that relies on them would not be trustworthy for security enforcement.

Relevant Upstream Issues

• anthropics/claude-code#4775 - current callbacks/hooks could not pause for user input; closed as not planned: [BUG][Typescript SDK] canUseTool callback in the Claude Code SDK is not working anthropics/claude-code#4775
• anthropics/claude-agent-sdk-python#200 - can_use_tool / PermissionResultAllow serialization bug: can_use_tool does not work when serializing PermissionResultAllow anthropics/claude-agent-sdk-python#200
• anthropics/claude-agent-sdk-python#304 - long-running approval timeout and apparent fail-open behavior: Feature Request: Support for Long-Running Tool Approval anthropics/claude-agent-sdk-python#304
• anthropics/claude-agent-sdk-python#227 - duplicate report that the example callback still did not work correctly: Can Use Tool is not working anthropics/claude-agent-sdk-python#227
• anthropics/claude-agent-sdk-typescript#19 - allowedTools not enforced: allowedTools Option does not work anthropics/claude-agent-sdk-typescript#19
• anthropics/claude-agent-sdk-typescript#29 - duplicate report that allowedTools and canUseTool were bypassed in some scenarios: Bug Report for Anthropic Claude Code SDK anthropics/claude-agent-sdk-typescript#29
• anthropics/claude-code#6305 - PreToolUse / PostToolUse not executing: Post/PreToolUse Hooks Not Executing in Claude Code anthropics/claude-code#6305
• anthropics/claude-code#10814 - hook regression around Claude Code 2.0.30 / 2.0.31: Hooks broken again in v2.0.31 (regression after v2.0.30 fix) anthropics/claude-code#10814

Proposed Enhancement

• Decide whether Janus should add a Claude Agent SDK adapter only when enforcement is local and fail-closed, or explicitly document Claude Agent SDK / Claude Code as unsupported for hard security enforcement until the upstream permission path is reliable.
• If we revisit support, add a minimal repro suite that verifies callback invocation on every tool call, deny-path enforcement in continued sessions / multi-turn runs, stable serialization, and fail-closed behavior on timeout.

[m13v]

this is an important question. we enforce tool boundaries through a combination of claude code hooks and file-based permission configs rather than relying solely on the SDK's canUseTool. the practical issue is that hooks can time out under load and the SDK doesn't guarantee the hook runs before tool execution in all edge cases. for policy enforcement at the tool-call boundary, having a secondary verification layer (checking results after execution) catches the cases where the pre-hook was skipped

[m13v]

Our tool execution and dispatch implementation that handles permission boundaries: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatToolExecutor.swift

The approach is: validate tool parameters before execution, execute in a sandbox, verify results after. The pre-execution validation catches most policy violations, but the post-execution check is the safety net for edge cases where the pre-hook didn't fire.

[eharris128]

Ty :)

Appreciate you sharing the reference.

[eharris128]

I think there is a viable path forward here that avoids the broken permission callback entirely.

The linked ChatToolExecutor.swift and mcp-server-macos-use code follow the right pattern: Claude acts as planner, but tool execution is owned by app/server code. That is already close to Janus's existing architecture: janus.llm.runner executes tools locally via the registry, and janus.llm.providers.anthropic_provider already translates Claude-style tool_use / tool_result blocks.

Because of that, I would scope this issue more narrowly as a secure Claude Code / Claude Agent SDK adapter, not generic Claude support. Main already supports Anthropic/Claude as a model provider; the blocker is specifically trusting Claude Code permissions/hooks as the enforcement boundary.

The upstream evidence still points the same way: issue anthropics/claude-agent-sdk-python#469 has reports that can_use_tool does not fire for built-in tool execution, including comments spanning SDK 0.1.19 / CLI 2.1.7, SDK 0.1.29 / CLI 2.1.31, and SDK 0.1.48 / CLI 2.1.73.

One useful concrete detail: local claude --help on 2.1.78 (Claude Code) confirms two flags that make a safer Janus design possible:

• --tools "" disables all built-in Claude tools
• --strict-mcp-config ignores other configured MCP servers

So the safe design for Janus support looks like this:

• Expose Janus ToolDefs as SDK MCP tools. Prefer create_sdk_mcp_server(...); an external MCP server would also work.
• Disable Claude built-in tools entirely via tools=[] / --tools "".
• Use only Janus MCP tools, e.g. allowed_tools=["mcp__janus__..."].
• Pass extra_args={"strict-mcp-config": None} so user/project/global MCP servers do not leak in.
• Optionally also set disallowed_tools=[...] as defense in depth.
• Keep Janus policy enforcement inside the tool handler / registry. Do not rely on can_use_tool or PreToolUse for hard security.
• Treat hooks as observability / UX only.

If someone picks this up, I think the acceptance criteria should be:

1. Built-in Claude tools (Write, Edit, Bash, etc.) are not available.
2. Only Janus-owned MCP tools are reachable.
3. Denied Janus tool calls fail closed and do not execute.
4. No user/project/global MCP config leaks into the session.
5. The design does not depend on can_use_tool or hook callbacks firing.

That makes the follow-up implementation fairly concrete:

• convert ToolDef -> SDK MCP tool schema
• route execution back through Janus registry / enforcer
• provide a minimal ClaudeSDKClient or query() example
• add a smoke test proving tools=[] + Janus MCP tools works on a pinned SDK / CLI version

Relevant references:

• [BUG] mismatch between the Claude CLI control protocol and can_use_tool permission anthropics/claude-agent-sdk-python#469 (comment)
• https://github.com/anthropics/claude-agent-sdk-python/blob/main/README.md
• https://platform.claude.com/docs/en/agent-sdk/hooks
• https://github.com/mediar-ai/mcp-server-macos-use/blob/main/Sources/MCPServer/main.swift
• https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatToolExecutor.swift

[m13v]

yeah exactly, the planner/executor split is the natural fit. in practice we found that having the tool executor own the permission boundary means you can swap out the permission policy without touching the LLM integration at all. the post-execution verification layer catches the edge cases where the planner's intent doesn't match what actually happened - which is surprisingly common with complex multi-step tool chains.