Double approval removed for planned task tools

aalises

·Apr 2, 2026·#27896fix: Auto-authorize task-family tools after plan approval

After approving an AI plan, n8n no longer asks for a second confirmation before executing non-destructive data table or workflow tools within that approved task family.

When users approve a plan containing AI tasks like table management or workflow building, they expect those tasks to run without further interruption. Instead, n8n was prompting twice — once for the plan, then again for each individual tool the sub-agent tried to use. Users saw their approved task fail with "Unauthorized" errors even though they'd already given consent.

The fix creates a task-scoped context when dispatching planned tasks. Plan approval now propagates into per-tool authorization for the task's non-destructive tools. Data table management tasks get auto-approved for create, schema mutate, and row mutate operations. Workflow build tasks get auto-approved for running and publishing. Destructive actions like table deletion remain gated — those still require explicit approval each time.

This applies to the instance AI module in n8n's CLI package, affecting how autonomous agents execute user-approved multi-step plans.

View Original GitHub Description

Summary

Fixes unauthorized creating tables

Problem

When a user approves a plan containing a manage-data-tables task, the sub-agent that runs it still triggers a second HITL confirmation for tools like create-data-table. The sub-agent treats the denied/timed-out confirmation as "Unauthorized" and the task fails — even though the user already approved the plan.

Root cause

Tools close over InstanceAiContext at creation time and check context.permissions?.createDataTable !== 'always_allow' on every call. All dispatched planned tasks share the same OrchestrationContext (and the same tool closures), so there's no mechanism for plan approval to propagate into per-tool authorization.

Solution

When dispatching a planned task, we now create a task-scoped OrchestrationContext with permission overrides based on the task kind. Domain tools are rebuilt from a cloned InstanceAiContext so each sub-agent gets its own closures with the correct permissions — no cross-task leakage.

The override mapping is a single constant:

Task kind	Auto-approved permissions
`manage-data-tables`	`createDataTable`, `mutateDataTableSchema`, `mutateDataTableRows`
`build-workflow`	`runWorkflow`, `publishWorkflow`
`research`	none
`delegate`	none

Intentionally excluded (still require explicit approval):

Destructive actions: delete-data-table (always suspends, no permission check)
Open-ended actions: fetch-url, read-file
Credential/workflow deletion

What changed

New: planned-task-permissions.ts — override mapping + applyPlannedTaskPermissions() helper
Modified: instance-ai.service.ts — dispatchPlannedTask creates a task-scoped context via createPlannedTaskContext()
Zero changes to tool implementations — leverages the existing context.permissions mechanism