Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

Relationships

#1080 runModel(): options.arguments never reach the child's per-method arguments — merged into globalArgs, then dropped or rejected

Opened by mgreten · 7/10/2026· Shipped 7/11/2026

Hi again! Second small finding from our context.runModel() migration today (same session as #1077 — and once more, thank you for this feature; the design is exactly what our nested-composition setup needed).

While converting our extensions we found that per-method arguments don't reach the child method in 20260710.223351.0. We hit it empirically first, then traced it in source at fb93097:

What we observe (two forms, two failures):

  1. By-definition form: context.runModel({ definition: "cli-agent", method: "invoke", arguments: { prompt: "..." } }) → the child's invoke sees prompt: undefined and fails with "Method arguments validation failed".
  2. By-type form (fresh name): → "Global arguments validation failed: Unknown argument(s): prompt, provider, ..." — the target's strict globalArguments schema rejects the method-arg keys outright.

Where it seems to come from:

  • src/domain/models/model_invocation_service.ts:171-173 merges options.arguments over definition.globalArguments and passes the result as the child context's globalArgs — method args are never populated separately.
  • src/domain/models/method_execution_service.ts:169 then reads the child's method arguments from the persisted definition (definition.getMethodArguments(context.methodName)), so the caller's arguments can never reach them; and the strict globalArgs validation (~line 133) rejects any method-arg keys that came along for the ride.
  • design/models.md shows arguments: { cidrBlock: "[IP-1]/16" } flowing into a create method, which reads as the intended behavior — so this looks like an implementation gap rather than a design choice (though happy to be corrected!).

Impact for us: every composition we're migrating passes per-call data (prompts, PR lists, browser command batches), so today the runModel path fails validation for all of them. The silver lining: the validation failure fires before the method body runs, so we've shipped our conversions as runModel-first with a cheap fall-back to our old shell-out on that error — zero behavior change now, and the runModel path will light up on its own once argument threading works. So there's no urgency on our end, just wanted to flag it while it's fresh.

Could a fix perhaps thread options.arguments through to the method-args resolution (e.g. merged over definition.getMethodArguments(...) before validation), rather than into globalArgs? Whatever direction you prefer, of course. Happy to test a build against our real extension chain — we have four converted call sites that would exercise it immediately. Thanks so much!

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/11/2026, 8:17:27 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/11/2026, 12:33:32 AM
Editable. Press Enter to edit.

stack72 commented 7/11/2026, 8:17:40 PM

Thanks @mgreten for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

mgreten commented 7/11/2026, 10:53:56 PM

Verified fixed on our real workload — thank you for the fast turnaround! On 20260711.221640.0 our adw-phase-runner → cli-agent chain now runs fully in-process: the child received its prompt method argument correctly (classification completed, 117s), and process-sampling during the run showed zero child swamp-bin processes where the shellout fallback used to spawn one. Our fallback predicates never fired. Exactly the behavior we hoped for — much appreciated!

Sign in to post a ripple.