Hi,
While reviewing the project architecture, I noticed a few core areas where the implemented behavior appears less complete than the exposed architecture/configuration suggests.
Main observations:
SessionManager.save() exists, but runtime code does not appear to call it, so sessions may not be persisted automatically.
CheckpointManager.save() exists, and /undo restores checkpoints, but file edit tools do not appear to create checkpoints before writes.
- Permission settings such as
allowedTools, deniedTools, allowRules, denyRules, and sandbox-related settings are defined, but the main permission checker does not seem to fully enforce them.
- A sandbox wrapper exists, but
BashTool appears to execute commands directly rather than routing through the sandbox layer.
AgentTool accepts isolation: "worktree", but worktree isolation does not appear to be implemented.
- Subagents currently appear to run with
bypassPermissions, which may be risky for real coding workflows.
- Provider support is uneven: Anthropic seems to be the primary path, while OpenAI/Google tool-use and streaming behavior look less complete.
A possible improvement would be to introduce a unified tool execution lifecycle, for example:
validate input
-> apply allow/deny rules
-> request permission if needed
-> create checkpoint for file mutations
-> apply sandbox or execution constraints
-> execute tool
-> run hooks
-> normalize result
-> persist session/audit state
This could make the agent safer and more predictable, while also making existing components like session management, checkpoints, permissions, and sandboxing actually work together.
Would these kinds of changes be useful to the project maintainers? If so, I’d be happy to help break this down into smaller PRs, for example:
- Wire session persistence into normal startup/shutdown or end-of-turn flow.
- Create checkpoints before
Edit, Write, and MultiEdit.
- Enforce
allowedTools / deniedTools in the permission checker.
- Route
BashTool through the sandbox wrapper when enabled.
- Implement or remove the currently advertised
worktree subagent isolation mode.
- Avoid default
bypassPermissions for subagents unless explicitly configured.
Thanks for the work on this project. I wanted to check whether these changes align with the intended direction before opening implementation PRs.
Hi,
While reviewing the project architecture, I noticed a few core areas where the implemented behavior appears less complete than the exposed architecture/configuration suggests.
Main observations:
SessionManager.save()exists, but runtime code does not appear to call it, so sessions may not be persisted automatically.CheckpointManager.save()exists, and/undorestores checkpoints, but file edit tools do not appear to create checkpoints before writes.allowedTools,deniedTools,allowRules,denyRules, and sandbox-related settings are defined, but the main permission checker does not seem to fully enforce them.BashToolappears to execute commands directly rather than routing through the sandbox layer.AgentToolacceptsisolation: "worktree", but worktree isolation does not appear to be implemented.bypassPermissions, which may be risky for real coding workflows.A possible improvement would be to introduce a unified tool execution lifecycle, for example:
validate input
-> apply allow/deny rules
-> request permission if needed
-> create checkpoint for file mutations
-> apply sandbox or execution constraints
-> execute tool
-> run hooks
-> normalize result
-> persist session/audit state
This could make the agent safer and more predictable, while also making existing components like session management, checkpoints, permissions, and sandboxing actually work together.
Would these kinds of changes be useful to the project maintainers? If so, I’d be happy to help break this down into smaller PRs, for example:
Edit,Write, andMultiEdit.allowedTools/deniedToolsin the permission checker.BashToolthrough the sandbox wrapper when enabled.worktreesubagent isolation mode.bypassPermissionsfor subagents unless explicitly configured.Thanks for the work on this project. I wanted to check whether these changes align with the intended direction before opening implementation PRs.