fix(cli): harden plan mode permissions and propagate restrictions to sub-agents#8417
Merged
Conversation
…erit caller edit restrictions
…estrictions to sub-agents
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Contributor
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Files Reviewed (1 files)
Reviewed by gpt-5.4-2026-03-05 · 197,147 tokens |
alex-alecu
approved these changes
Apr 6, 2026
…ion status text When plan mode delegates to a subagent the child session can block on a permission or question before the UI starts tracking it, leaving the parent stuck on 'Delegating work' with no visible prompt. - Auto-adopt child sessions in KiloProvider.handleEvent as soon as the task tool part reveals metadata.sessionId — eliminates the race where the child emits a prompt before the webview renderer calls syncSession - Add fetchAndSendPendingQuestions mirroring the existing permission recovery; call both after handleSyncSession so missed prompts are recovered for child sessions - Extend questionCtx with trackedSessionIds + sessionDirectories needed for the recovery path - Improve statusText: when delegating and the session family has pending permissions/questions, show 'Subagent waiting for permission' or 'Subagent waiting for response' instead of generic 'Delegating work' - Add i18n keys for the two new status strings across all 19 locales
This was referenced Apr 9, 2026
jliounis
pushed a commit
to jliounis/kilocode
that referenced
this pull request
May 18, 2026
fix(cli): harden plan mode permissions and propagate restrictions to sub-agents
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
2 participants
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
Fixes two related security/correctness issues with plan mode permissions and sub-agent isolation.
This PR also incorporates the guidance and changes from PR #8360, which identified that
apply_patchandwritetool permissions were not properly restricted in plan mode.Problems Found
1. Plan mode could silently hard-block the model with no recourse
Plan mode had
edit: { "*": "deny" }— any attempt to edit a file outside.kilo/plans/would throw a hard error that the model couldn't recover from. This caused confusing failures when a sub-agent or the plan agent itself tried to do something reasonable (e.g. update a config file the user approved).2. Sub-agents did not inherit the calling agent's restrictions
When the plan agent spawned a sub-agent (e.g.
generalorexplore) via thetasktool, the child session was created with onlytodowrite/todoreaddeny rules. The sub-agent's own agent definition was used for everything else — which has fully permissiveeditand standardbashpermissions. This meant a sub-agent could freely write any file, bypassing plan mode entirely.3. Plan mode had unrestricted bash access
The plan agent inherited
defaultsbash rules, which allow write operations (touch,mkdir,cp,mv) without restriction. Plan mode is supposed to be read-and-plan-only, so these should require approval or be blocked.4. MCP tools were unavailable in plan mode
Plan mode had no MCP rules, so all MCP tool calls were denied. The ask agent (PR #7929) already solved this pattern with per-call approval — plan mode should benefit from the same.
5. Specific MCP tool restrictions were dropped when propagating to sub-agents
The inheritance filter in
task.tsonly preserved server-wide wildcard rules likegithub_*. Narrower rules targeting individual tools (e.g.github_create_issue: deny) were silently dropped, so sub-agents fell back to their own permissive*rule for those tools.Changes
packages/opencode/src/agent/agent.ts.kilo/plans/*.md)touch,cp,mv, …)cat,grep,git log, …)packages/opencode/src/tool/task.tsWhen any agent spawns a sub-agent via the
tasktool, the child session now inherits the calling agent'sedit,bash, and MCP permission rules. Because permission evaluation usesfindLast, the inherited rules are appended last and take precedence over the sub-agent's own defaults.plan→generalsub-agent edit any fileedit: "*": "ask"plan→generalsub-agent edit plan fileplan→generalsub-agent bash write commandsreadOnlyBashorchestrator→ sub-agent bashbash: "deny"code→ sub-agent editgithub_*: deny)github_create_issue: deny)Related
apply_patch/writepermissions were not restricted in plan mode; its guidance has been incorporated into this PRreadOnlyBash+ MCP for Ask agent (reused here for plan mode)