## Description
Use one decision endpoint for Approve once, Approve for session, and
Reject. Concurrent session approvals lock the session before updating
requests to prevent conflicting lock order.
Keep approval outcomes available after decisions and reloads as compact,
neutral conversation rows. Details start collapsed. Expired rows state
that the action did not run; only pending requests show an attention
border and decision buttons. The server decides whether a request is
still live; a user's device clock cannot disable it. History includes
live requests and the 50 most recent outcomes. Polls read small status
records and refresh full history when statuses change.
The proxy still waits up to 180 seconds. This is a network wait, not
durable paused execution. Expired requests show Expired, and late
decisions return a conflict. Agent permission requests that cannot
resume fail scheduled runs with a clear reason. Losing an execution
lease aborts the agent.
The plugin editors and personal/task permission controls are in the
preceding PR, #16185. Approval queries remain in the existing Craft DB
module, as requested for this feature.
## How Has This Been Tested?
- Ten approval-card/history tests pass, including collapsed neutral
expiry, detail expansion, and live-request controls.
- A browser check confirmed the neutral expired row and unchanged
pending controls.
- 82 gate unit tests passed after restoring the Craft DB module.
- Earlier verification passed 21 approval API database tests, including
concurrent session grants, retries, conflicting decisions, history, and
expiry.
- Earlier local Kind checks covered concurrent grants, a browser clock
ten minutes ahead, and approved history after reload.
- A scheduled worker requested approval without an open browser;
approval resumed execution and produced the expected result.
- An actual 180-second timeout blocked forwarding and rejected a late
decision.
- Follow-up verification passed 39 approval/executor database tests, 550
proxy unit tests, and five route-contract tests.
## Additional Options
- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
- [x] [Optional] Override Linear Check
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Approval cards now offer **Approve once**, **Approve for session**,
and **Reject** in one flow, with session-wide approval available when
eligible.
* Session approval history now shows pending, approved, rejected, and
expired requests. Status updates are checked automatically, and changed
statuses refresh the history.
* Cards show approval deadlines and present completed requests as
compact, expandable outcomes.
* **Bug Fixes**
* Scheduled runs that need unavailable permissions now finish as failed
runs instead of waiting for approval.
* Expired approval messages clarify that the action did not run.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Description
Give each user and scheduled task its own action settings.
Workspace-disabled actions always remain blocked. Admins can require
workspace settings or let users choose their own settings.
Scheduled tasks now show app and MCP cards. Apps start disabled. When
creating a task, enabling an app copies the user's current settings.
Existing tasks keep their saved choices when apps are enabled again;
missing choices require approval. Later requests use the task's saved
settings and current workspace restrictions.
One migration replaces app-wide task pre-approvals with per-action
settings. Existing tasks receive auto-approval only for known actions in
apps they already pre-approved. Apps remain enabled even if they have no
known actions. New actions require approval. The migration remains with
the code that reads the new tables.
Action recognition identifies the request. One policy resolver then
applies workspace restrictions, task membership, personal or task
settings, and session grants. Failed recognition or policy lookup blocks
the request. A completed scheduled session cannot use personal settings
for later requests.
The next PR adds app settings editors. This PR includes the task editor
because its payload changes with the task API.
## How Has This Been Tested?
The complete stack passed 71 local Kind scenario checks, covering
browser editing, persistence, access restrictions, real proxy requests,
and scheduled execution. Checks include a real 180-second approval
timeout, live policy changes, and completed-task request rejection.
This PR’s intermediate tree passed 1,053 backend unit tests, 148
database tests, five route-contract tests, and 39 frontend tests. Python
and TypeScript checks and changed-file pre-commit checks passed.
No migration was applied to the user's database during this
verification.
## Additional Options
- [ ] [Optional] Please cherry-pick this PR to the latest release
version.
- [x] [Optional] Override Linear Check
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added per-action approval settings for connected apps and MCP tools,
with workspace, personal, and scheduled-task controls.
* Scheduled tasks can enable apps and configure individual actions when
creating or editing tasks; settings are also visible on task details.
New tasks start with apps disabled.
* Policy editors support searching, bulk changes, and resetting editable
choices.
* **Security & Permissions**
* Workspace restrictions remain binding, and task settings are checked
during active runs.
* Actions requiring approval still prompt users when app credentials are
unavailable.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Wenxi