From 6f72d369bf1a966facb6baf88b31a2d0c0f2b97b Mon Sep 17 00:00:00 2001 From: Scott Werner Date: Fri, 4 Sep 2026 16:59:44 -0400 Subject: [PATCH] Document that fabro_run_create does not apply user run defaults Tool-created runs no longer layer the caller's ~/.fabro/settings.toml [run] defaults or project and machine run settings; only the values in the request are transmitted, matching fabro run. The PR body stated this but the public MCP and child-run docs did not, so callers relying on an auto_approve or model default would see runs pause for approval or use the default model without explanation. Note the behavior in both pages and point at the explicit spec fields to use instead. Co-Authored-By: Claude Fable 5.1 --- docs/public/agents/mcp.mdx | 2 ++ docs/public/execution/child-runs.mdx | 2 ++ 2 files changed, 4 insertions(+) diff --git a/docs/public/agents/mcp.mdx b/docs/public/agents/mcp.mdx index 0bf9a0921..f7abd2c29 100644 --- a/docs/public/agents/mcp.mdx +++ b/docs/public/agents/mcp.mdx @@ -159,6 +159,8 @@ Use `goal` for inline goal text or `goal_file` to read the run goal from a file. Creation and execution remain separate operations. `fabro_run_create` first creates a durable run, then requests one start by default. Set `start: false` to leave the new run submitted without requesting execution. +`fabro_run_create` transmits only the values in the request. The MCP server's `~/.fabro/settings.toml` `[run]` defaults, and any project or machine run settings, are not applied to the created run, matching `fabro run`. Keep workflow-owned behavior in `workflow.toml`, and pass explicit `auto_approve`, `dry_run`, `model`, `provider`, `environment`, or `preserve_sandbox` values in the spec when a run needs them. + Run summaries returned by the MCP server include parent metadata. Use `parent_id` on `fabro_run_create` to create a child run, `parent_id` on `fabro_run_search` to list direct children, and the `link_parent` or `unlink_parent` actions on `fabro_run_interact` to change an existing run's parent. See [Child Runs](/execution/child-runs) for the orchestration model. Pending runs can be approved or denied through `fabro_run_interact`: diff --git a/docs/public/execution/child-runs.mdx b/docs/public/execution/child-runs.mdx index 0158c8469..6b07604fe 100644 --- a/docs/public/execution/child-runs.mdx +++ b/docs/public/execution/child-runs.mdx @@ -138,6 +138,8 @@ Workflow content and workspace target are separate choices. If `target` is omitt `goal_file` is also a shared-filesystem feature. Local agents can read it relative to the operation `cwd`; Docker and Daytona agents must send the resolved `goal` text by value. +Like `fabro run`, `fabro_run_create` transmits only what the request names. Run defaults from the caller's `~/.fabro/settings.toml` `[run]` table, and project or machine run settings, are not applied to the created run. Put workflow-owned behavior in the workflow's `workflow.toml`, and pass explicit `auto_approve`, `dry_run`, `model`, `provider`, `environment`, or `preserve_sandbox` values in the spec when a child needs them. See [Run Configuration](/execution/run-configuration) for the settings layering. + By default, `fabro_run_create` requests start for each created run. Set `"start": false` when the parent should create the child now and start it later. ## Start and approval