packages/sdk/src/authored-worker-step.ts validates options.cwd (f.agent options.cwd must be a string when set) and lowers it into the step spec (...(options.cwd === undefined ? {} : { cwd: options.cwd })), but the kernel refuses the field:
FAILED [protocol_error] relayflowd could not complete the run request:
invalid_spec: unknown field "cwd" at steps[0] — refusing to guess (fail closed)
Reproduced on relayflows 2.0.21 with flows run --local-agent and a two-step flow whose first f.agent sets cwd. flows check passes — nothing catches it before the run.
Either the kernel should accept cwd on agent/llm steps (run the CLI in that directory, still inside the run's tree) or the SDK should refuse it at authoring time with a named refusal and flows check should catch it. Accepting-then-refusing at dispatch is the worst of the three. If cwd is meant to be expressed another way (workspace surfaces?), say so in docs/SURFACE.md where AgentOptions is documented.
Found while writing a multi-repo flow that drives agents in two checkouts.
packages/sdk/src/authored-worker-step.tsvalidatesoptions.cwd(f.agent options.cwd must be a string when set) and lowers it into the step spec (...(options.cwd === undefined ? {} : { cwd: options.cwd })), but the kernel refuses the field:Reproduced on relayflows 2.0.21 with
flows run --local-agentand a two-step flow whose firstf.agentsetscwd.flows checkpasses — nothing catches it before the run.Either the kernel should accept
cwdon agent/llm steps (run the CLI in that directory, still inside the run's tree) or the SDK should refuse it at authoring time with a named refusal andflows checkshould catch it. Accepting-then-refusing at dispatch is the worst of the three. Ifcwdis meant to be expressed another way (workspace surfaces?), say so in docs/SURFACE.md whereAgentOptionsis documented.Found while writing a multi-repo flow that drives agents in two checkouts.