policy: support commands with a value before a further subcommand, e.g. fj issue edit N title #52

New issue

Closed

opened 2026-10-08 10:47:00 +02:00 by pti · 0 comments

pti commented

2026-10-08 10:47:00 +02:00

Owner

Commands that take a value and then a further subcommand cannot be called through wraptool. The first one hit is fj issue edit <ISSUE> <title|body|comment|labels>.

What happens

With an approved allow rule for fj issue edit, the call fj_issue_edit(args: ["50", "body", "help"]) fails:

error: unexpected argument 'body' found
  tip: subcommand 'body' exists; to use it, remove the '--' before it

wraptool puts -- before positional arguments so they can never be read as flags. That is the right default, but it also stops a CLI from treating anything after the value as a subcommand. No policy change can make fj issue edit work today.

A second obstacle

edit … body and edit … title most likely take the new text as a positional argument. The argument sanitizer rejects backticks and parentheses, so Markdown cannot go through even once the -- problem is solved. fj issue create and fj pr create get around this with --body-file; check whether edit has an equivalent.

Possible directions

Allow-rule subcommand paths with a placeholder for a value, for example ["issue", "edit", "*", "title"], where * matches one constrained positional (type and shape checked) and -- goes after the whole path.
A per-tool or per-rule way to pass long or free text through a file wraptool writes, rather than through argv. This is related to design/free-text-sanitization-tier.md.

Done when

fj issue edit <N> title <text> works under an allow rule with a placeholder, the placeholder is validated, flag injection stays impossible, and there are tests for the argv wraptool builds.

🤖 Generated with Claude Code

Commands that take a value and then a further subcommand cannot be called through wraptool. The first one hit is `fj issue edit <ISSUE> <title|body|comment|labels>`. ## What happens With an approved allow rule for `fj issue edit`, the call `fj_issue_edit(args: ["50", "body", "help"])` fails: ``` error: unexpected argument 'body' found tip: subcommand 'body' exists; to use it, remove the '--' before it ``` wraptool puts `--` before positional arguments so they can never be read as flags. That is the right default, but it also stops a CLI from treating anything after the value as a subcommand. No policy change can make `fj issue edit` work today. ## A second obstacle `edit … body` and `edit … title` most likely take the new text as a positional argument. The argument sanitizer rejects backticks and parentheses, so Markdown cannot go through even once the `--` problem is solved. `fj issue create` and `fj pr create` get around this with `--body-file`; check whether `edit` has an equivalent. ## Possible directions - Allow-rule subcommand paths with a placeholder for a value, for example `["issue", "edit", "*", "title"]`, where `*` matches one constrained positional (type and shape checked) and `--` goes after the whole path. - A per-tool or per-rule way to pass long or free text through a file wraptool writes, rather than through argv. This is related to `design/free-text-sanitization-tier.md`. ## Done when `fj issue edit <N> title <text>` works under an allow rule with a placeholder, the placeholder is validated, flag injection stays impossible, and there are tests for the argv wraptool builds. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

pti referenced this issue from a commit

2026-10-19 23:34:19 +02:00

feat(policy): allow-rule placeholders for a value that precedes a further subcommand

pti referenced this issue from a pull request that will close it,

2026-10-19 23:34:45 +02:00

feat/policy: allow-rule placeholders for a value that precedes a further subcommand #105

pti closed this issue

2026-10-19 23:36:13 +02:00