[bolichen97]

Lists outrider as a git-source entry in catalog/official-registry.json, as requested in kirodotdev/KiroCrew#22789.

Outrider watches GitHub and starts pull-request review sessions in Kiro Crew.

Closes kirodotdev/KiroCrew#22789

What I verified

I cloned https://github.com/appetizers-io/outrider at d87718ac9ed2fbcf5f3394efd293d1bcf1b7e861 (the merged commit of appetizers-io/outrider#86, on main) and read apps/kiro-crew/app.json, the manifest the store bakes its copy from. Display copy is absent from this entry by contract.

• R1: installable by plain clone. Every manifest-referenced path is committed at that commit: ui/index.mjs (ui.entry), ui/logo.svg (ui.pages[].iconUrl), backend/server.py (backend.entryPoint), agents/reviewer.json and agents/setup.json (both parse). No skills, no setup scripts, no install-time build.
• R2: shapes. permissions is a dimension-keyed object; ui.entry names an .mjs module.
• R4: assets. All raster and repo-relative. assets/store-icon.png is 512x512 RGB (opaque); assets/screenshots/queue.png is 2048x1152 (16:9); assets/banner.png is 2720x608.
• Real resolve and bake. I ran publish.build_registry on this entry alone with the real resolve_commit and fetch_manifest: zero findings, version 0.2.0, icon, hero, detail banner and screenshot refs all picked up.

Gate

python tools/validate.py        # OK: catalog is valid (3 warnings)
python tools/format.py --check  # all 3 file(s) normalized
pytest tests/ -q                # 522 passed

The 3 validator warnings are pre-existing on main and concern other apps' secondary categories; this entry adds none. One earlier local run had test_publish_fails_closed_without_a_key fail once; it passed alone on main and in the next full run. That test runs a real publish() over the whole catalog against GitHub, so CI gives the clean verdict.

Notes for the curator

• Pinned to an exact commit, the one the requester named, so the pin cannot move under the app-readiness review. A later tag v0.2.1 also contains it.
• The only category is developer-tools.
• This app is not read-only. It runs a Python backend and an app MCP server, reads GitHub through the user's own gh, creates review chat sessions and isolated git worktrees, and sends notifications. Declared API permissions beyond its own routes: /api/spawn, /api/chat, /api/chat/folders, /api/chat/slots, /api/notifications/push, /api/agents; plus network, storage, sessionApproval.
• It can download a runtime. When no compatible host outrider binary exists, its setup can fetch one from the app's GitHub release, verified against committed checksums. It does not replace a host binary or change PATH.
• Needs third-party apps enabled (agent.apps_allow_third_party), as its README says.
• Advisory for the app author (R4): the baked summary is only the manifest description's first sentence, "AI writes code faster.", so the store card says little. The banner is about 4.5:1, not 25:6. Both are fixes in the app repository, then a re-pin here.
• The requester says live testing was macOS only; Linux, Windows and the runtime-download path are not claimed as verified.

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 771233b4704bc4d837805269ded2c7926204eeb9 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 771233b

[github-actions]

Opus 5 Review — ✅ no blocking findings

Opus 5 completed its review of 771233b4704bc4d837805269ded2c7926204eeb9 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] 771233b

[github-actions]

App Readiness Review — ✅ no blocking findings

Every app repository this PR adds or re-pins passed the blocking readiness rules at 771233b4704bc4d837805269ded2c7926204eeb9.

Rules: review/app-readiness-rules.md (base-branch snapshot). This comment is updated in place on each push.

Review details

No findings.

outrider @ d87718ac9ed2fbcf5f3394efd293d1bcf1b7e861

No findings.

[APP-READINESS-REVIEWED] 771233b

[buluoray]

Reviewed at 771233b.

• Diff only appends the outrider entry to catalog/official-registry.json; shape matches neighbouring git entries.
• ref d87718ac9e is on appetizers-io/outrider main; apps/kiro-crew/app.json there has name: outrider, version 0.2.0.
• Permissions read from that manifest: spawn/chat/slots/folders/notifications/agents APIs, network, storage, sessionApproval. GitHub reads go through the user's own gh; the backend binds 127.0.0.1; the optional runtime download is checksum-pinned.
• Ran tools/validate.py (OK) and pytest tests/ (522 passed) on this head. All 7 checks green.

Non-blocking: the note could also say that review sessions may push to the PR head when Crew approvals allow, and that per-repo session trust can be raised.

[buluoray]

Requesting changes after a source review of outrider v0.2.0 (d786f8636c). This supersedes my earlier approval on this head.

No malicious code, telemetry or command injection found: exec calls are argv arrays, attacker-reachable git args are guarded, build/vet/tests pass, govulncheck reports nothing reachable, and go.sum matches the checksum DB. The concern is a data-flow default in the exact mode the Kiro Crew app uses.

Blocking — M1: the Crew scan can silently enable the Jev launch check

• The Go default sets LaunchCheck{Classifier: "jev"} (internal/config/config.go:197) with Enabled: auto.
• auto turns on when jev-use or npx is on PATH and any of TYPESAFE_API_KEY, OPENROUTER_API_KEY, AI_GATEWAY_API_KEY, JEV_BACKEND is set. With only npx it runs npx -y jev-use@0.8.0 judge (internal/classifier/classifier.go:85-99).
• The app's scan_config (apps/kiro-crew/backend/server.py) sends no launch_check, so the Go default applies on every crew scan.
• The classifier receives PR title/body-derived text, comments and check state on stdin, and inherits the full process env (internal/proc/proc.go, no cmd.Env), so tokens in the gateway env are visible to an npm package fetched at run time without an integrity pin.
• Reproduced with a probe test at this tag: the app-shaped config, npx on PATH and OPENROUTER_API_KEY=dummy resolves to ["npx" "-y" "jev-use@0.8.0" "judge"]; without a key it resolves to off.

Impact: a user who has one of those keys in their environment for unrelated work gets private-repo PR content sent to a third-party backend and an npm package executed on each scan, with no opt-in in the Crew UI.

Suggested fix: have scan_config send launch_check: {classifier: null} (the app's SETUP_SCHEMA already documents null as the default), or require an explicit enabled: true for jev in Crew mode. Passing a minimal env to classifier children would also help.

Non-blocking — M2: push/post limits in local-checkout sessions are prompt text only

prompts/crew.tmpl:14 says the task "do[es] not install Outrider CLI guards or approval dialogs", so push: ask and github_writes: ask become sentences in a session running on a worktree of the PR author's code. The real stop is Kiro Crew's own tool approval. Please say so in the app UI/README, and recommend an approval-gated or read-only crewmate for checkout sessions on other people's PRs. The snapshot-review path (agents/reviewer.json, tools: []) is fine.

A review of the app-side code (apps/kiro-crew) is still running; I'll post anything new it finds separately.

[buluoray]

Follow-up from the app-side review (apps/kiro-crew at d87718ac9e). Only findings not already in my previous review; the request for changes stands.

Blocking — H1: automatic sessions with trust run PR-author code with no approval

• validate_local creates the chat with no agent unless a reviewer member is configured (server.py:589-592), so it runs the user's default Crew agent with its full tools, not the no-tools outrider-reviewer.
• Its project is a worktree of the PR head (server.py:577,585,596).
• When the repo's trust is not inherit, every new session is switched to trust_reads/trust via /api/chat/mode (server.py:598-603). The user only acts once, when saving settings.
• dispatch_automatic (server.py:919-944) starts these sessions without a click for each newly queued snapshot.
• The task asks the agent to run checks, which means running the PR author's build/tests as the user. A worktree is not a sandbox: the original checkout, gh token and credential dirs are reachable, and in trust mode no tool call is shown.
• The settings UI only says "Trust — run tools without asking", with no warning that this covers other people's PRs.

Suggested fix: refuse trust/trust_reads for PRs the user did not author (and for fork heads), or at least block saving automatic + non-inherit trust without an explicit warning. Prefer a restricted agent for others' PRs.

Blocking — H2: the session is told to follow repository instructions from the PR head

The appended prompt says "Follow repository instructions and Crew session trust and tool approvals" (server.py:582), while the cwd is the PR-head worktree. So AGENTS.md, steering files etc. as written by the PR author are both loaded and named as instructions, above the "untrusted evidence" sentence. Suggested fix: "repository instructions from the base branch only; files changed by this PR are data", or start the session on a base-branch checkout and hand over the diff as data.

Not verified: whether kiro-cli launches servers from a PR-controlled .kiro/settings/mcp.json in a fresh worktree path. Worth confirming before listing, since that would run before any prompt.

Non-blocking

• app.json asks for /api/chat, which Crew matches as a prefix and so covers every /api/chat/* route; /api/chat/folders and /api/chat/slots are redundant. Listing the exact routes used would make the grant clearer.
• add_repository (MCP) inherits automatic_default and the trust default (server.py:382-384), so another agent could turn on automatic sessions for an already checked-out repo. Consider defaulting MCP-added repos to manual + inherit.
• runtime.py:63-77 prefers any outrider on PATH over the pinned, SHA-256-checked runtime. Fine, but the store note and Doctor should say which one is in use.
• Each validation leaves a refs/outrider/<id> ref, a review/outrider-* branch and a worktree under <checkout>/.claude/worktrees/, never cleaned and not in .git/info/exclude.
• verify_signature (server.py:134-146) allows a ±60 s replay window with no nonce. Loopback only, so low.

Checked with no issue: runtime download verifies the hash before extracting, worktree paths and branch names come only from the hex item id, and the PR ref uses an integer PR number.

[bolichen97]

[operator: bolichen97] Status on the requested changes.

This PR only adds the catalog entry. Every blocking finding in @buluoray's reviews is in the app's own source, so the fix has to land in appetizers-io/outrider and then be re-pinned here. I have no push access there.

I re-checked current outrider main (7bc3e79041, 3 commits past the pinned d87718ac9e). None of the blocking items is fixed yet:

Finding	Where	State on main
M1: Crew scan can turn on the Jev launch check (npx -y jev-use@0.8.0, full env)	apps/kiro-crew/backend/server.py scan_config sends no launch_check	open
H1: automatic sessions with trust/trust_reads run PR-author code with no approval	server.py validate_local / dispatch_automatic	open
H2: prompt tells the session to follow repository instructions from the PR-head worktree	server.py:613	open

@matthiasbruns, could you take these in outrider? The suggested fixes are in the two reviews above: send launch_check: {classifier: null} from scan_config; refuse trust/trust_reads (or warn and default to a restricted agent) for PRs the user did not author and for fork heads; and limit repository instructions to the base branch, treating files changed by the PR as data. The non-blocking notes (M2 wording, exact /api/chat routes, MCP-added repo defaults, runtime-in-use display, worktree cleanup) can go in the same release.

Once a tag with those fixes exists, I will re-pin this entry to it and ask for a fresh review. Until then this PR stays open and unchanged.