Skip to content

feat(core): add "allow for session" permission reply - #60923

Closed
zed-0xff wants to merge 1 commit into
anomalyco:devfrom
zed-0xff:session-permission
Closed

feat(core): add "allow for session" permission reply#60923
zed-0xff wants to merge 1 commit into
anomalyco:devfrom
zed-0xff:session-permission

Conversation

@zed-0xff

@zed-0xff zed-0xff commented Oct 31, 2026 •
edited by opencodejr Bot
Loading

Copy link
Copy Markdown

Summary

  • Adds a session permission reply, shown as Allow for session in the TUI prompt, between "Allow once" and "Always allow".
  • It allows the request's exact resources for the rest of that session. Nothing is saved to the project.
  • Grants are held in memory per session and action, and matched literally, so a command containing * or ? is not widened into a wildcard. Configured deny rules still win.
  • Other pending prompts in the same session that the grant covers are answered automatically.
  • PermissionReply and the client types are regenerated.

Not covered: the mini footer TUI, the desktop app dock and the ACP adapter still offer only once, always and reject.

Testing

  • packages/core: bun test test/permission.test.ts (new test for exact-match session grants)
  • bun typecheck in packages/schema, packages/core and packages/tui

Visual

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 240 72" width="240" height="72" fill="currentColor" font-family="monospace" font-size="9">
  <text x="8" y="14" opacity=".6">△ Permission required</text>
  <text x="8" y="28">$ cp a.jpg b.jpg</text>
  <text x="8" y="52" opacity=".6">Allow once</text>
  <text x="76" y="52" font-weight="bold">Allow for session</text>
  <text x="170" y="52" opacity=".6">Reject</text>
  <rect x="72" y="58" width="92" height="2" opacity=".8">
    <animate attributeName="opacity" values=".8;.2;.8" dur="2s" repeatCount="indefinite"/>
  </rect>
</svg>

🤖 Generated with Claude Code

Added by the opencode bot (AI-generated).

Related: #48456, #50600

Public API: adds session to Permission.Reply (permission reply decision, permission.replied event reply, client PermissionReply types; backwards compatible for callers)

Andrey "Zed" Zaikin @claude
feat(core): add "allow for session" permission reply
15c4809 
Adds a `session` reply that allows the exact resources of a request for the
rest of the session without saving a project-wide rule. Resources are matched
literally and kept in memory. The TUI permission prompt offers the new option.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
@github-actions github-actions Bot added the needs:compliance This means the issue will auto-close after 2 hours. label Oct 31, 2026
@github-actions

github-actions Bot commented Oct 31, 2026

Copy link
Copy Markdown
Contributor

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

  • PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 72 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

opencodejr[bot]
opencodejr Bot reviewed Oct 31, 2026
View reviewed changes

@opencodejr opencodejr Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core part works as described. A session reply allows exactly the requested resources in that session only. It also answers other pending requests in the same session that are fully covered, and leaves partly covered requests and other sessions untouched. I checked this with the PR's test file, an extra throwaway core test, the ACP permission tests and type checks. I couldn't get the TUI to show a permission prompt in my headless harness. Could you attach before/after screenshots (or a short video) of the TUI prompt with the new Allow for session option?

Public API: Permission.Reply gains "session" (once | always | reject → once | session | always | reject). This affects the decision field of the permission reply HTTP endpoint, the reply field of the permission.replied event, and PermissionReply / PermissionReplyInput in @opencode/client. It is backwards compatible for callers. Plugins or clients that switch over the permission.replied reply value will now also see session.

Concerns:

  • packages/protocol/openapi.json was not regenerated: bun run check:generated in packages/protocol fails, and Permission.Reply there still lists only once, always and reject. Please run bun run generate in packages/protocol.
  • Grants only apply to the session that asked, so subagents (which run in their own child sessions) will prompt again; see the inline comment.
  • The reformatting of the two shell-scanner test cases in permission.test.ts is unrelated and can be dropped so the diff stays focused.

Related: #48456, #50600

Comment thread packages/core/src/permission.ts
)
})

function granted(input: Pick<Request, "sessionID" | "action" | "resources">) {

@opencodejr opencodejr Bot Oct 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grants are keyed by the request's own sessionID, so a subagent's child session never inherits them. If a user picks Allow for session in the parent, the subagent will ask again for the same command. If they pick it on a subagent's prompt, it covers only that child. In #48456, 14 of the 15 commands came from a subagent, so this is the case people are likely to hit. Was it meant to work this way, or should the grant be stored on (and checked against) the root session?

@github-actions

github-actions Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

This pull request has been automatically closed because it was not updated to meet our contributing guidelines within the 72-hour window.

Feel free to open a new pull request that follows our guidelines.

@github-actions github-actions Bot removed the needs:compliance This means the issue will auto-close after 2 hours. label Nov 3, 2026
@github-actions github-actions Bot closed this Nov 3, 2026
@Project579 Project579 mentioned this pull request Nov 7, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@opencodejr opencodejr[bot] opencodejr[bot] left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@zed-0xff