fix(security): route tracker imports through vetted issue creation - #1982

The direction is right and the label and tracker handling hold up, but the documented $(cat …) command cannot run under the secure setup, so every GitHub import would stop at creation until the title reaches vetted-op another way.

Golden rule — launch vetted operations with the literal ~ path (plugins/magpie-security/skills/issue-import/apply.md:52)

The same holds for the eval wrapper, ~/.claude/scripts/magpie-run-evals.sh, and for any sandbox-excluded command:
write it bare, with the literal ~, as the whole command line (not behind env or command), or it runs inside the sandbox and fails.

"$(cat <scratch>/issue-title-<threadId>.txt)" \

The $(cat …) keeps the command from matching the sandbox exclusion, so under the secure setup vetted-op runs inside the sandbox and fails before it reaches GitHub. I confirmed this with a read-only vetted-op-read --caller "$(echo …)" viewer, which dies with PermissionError: Operation not permitted while loading the policy; the same command without the substitution works. Since this step says to stop on failure and never fall back to raw gh, every GitHub import stops here. The same applies to issue-import-from-md/SKILL.md:362 and issue-import-from-pr/SKILL.md:470 and :472. Inlining the title is not an option, because it is attacker-controlled. Let issue-create-labeled take the title as a file in the workspace, validated like the body and passed to gh as -F title=@<file>, so the command needs no substitution. The labels can be written inline as a literal JSON argument, since they come from configuration rather than from the report.

Smaller observations

• tools/vetted-ops/README.md:618 — The table below now has eleven rows. The same text is in the plugins/magpie-vetted-ops copy. Update the count, or move the GitHub-only row out of this table.
• general — The eval box is unticked and the test plan names no eval run, while the PR changes the security-issue-import, -from-md and -from-pr skills and adds setup fixtures. Run those three suites and the two setup suites, and record the result in the PR.
• See inline comments on tools/vetted-ops/src/vetted_ops/ops.py:1107.

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. After you've
addressed the points above and pushed an update, an Apache Magpie
maintainer — a real person — will take the next look
at the PR. The findings cite the project's review criteria;
if you think one of them is mis-applied, please reply on the
PR and a maintainer will weigh in.

More on how Apache Magpie handles maintainer review:
Contributing guide.

Thanks for this. I applied the changes myself rather than asking for another round, because I want to bump the dev version with this fix in it, and I rebased the branch onto main. Please pull before pushing again.

What changed in 182a872:

• issue-create-labeled now takes the title as a workspace file, read and validated by the dispatcher like the body (tools/vetted-ops/src/vetted_ops/ops.py, cli.py), so the commands in issue-import/apply.md, issue-import-from-md/SKILL.md and issue-import-from-pr/SKILL.md have no $(cat …) and run under the secure setup. The labels are written inline.
• A dry run never prints a title read from a file, and a refused title file is not quoted in the error, because a dry run accepts any --config.
• The README now says eleven operations.

The title still reaches gh as an argument inside the dispatcher, the same way issue-create does it. It never reaches a shell, so I left that as it is.

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Magpie handles maintainer review:
Contributing guide.