The README recommends --dangerously-skip-permissions as the intended workflow. Looking at gsd-executor.md you can see why — subagents run node gsd-tools.cjs, git checkout -b, eslint, test runners, all generated dynamically by the planner. Approving each one kills autonomous mode.
There is a gsd-plan-checker that runs before execution, but it only verifies logical completeness — requirement coverage, dependency graphs, context budget. It never looks at what commands will actually run. So if the planner generates something destructive, the plan-checker won't catch it because that's not what it checks for. The gsd-verifier runs after execution, checking whether the goal was achieved, not whether anything bad happened along the way. In /gsd:autonomous this chains across all remaining phases unattended.
The granular permissions fallback in the README only covers safe reads and git ops — but the executor needs way more than that to actually function. Feels like there should be a permission profile scoped to what GSD actually needs without going full skip.
The OSWorld numbers are kinda getting lost in the pricing discussion but imo that's the most interesting part. Mini at 72.1% vs 72.4% human baseline is basically noise, so why not just use mini by default unless you're hitting specific failure modes.
Also context bleed into nano subagents in multi-model pipelines — I've seen orchestrators that just forward the entire message history by default (or something like messages[-N:] without any real budgeting), so your "cheap" extraction step suddenly runs with 30-50K tokens of irrelevant context. And then what's even the point, you've eaten the latency/cost win and added truncation risk on top.
Has anyone actually measured where that cutoff is in practice? At what context size nano stops being meaningfully cheaper/faster in real pipelines, not benchmarks.
The pipeline ordering is smart — L8 identity running before anything touches the ingestion layer means a rogue agent gets rejected before it even gets to inject anything. I've seen a couple agent wrappers that run input scanning first and only check identity after, which is just asking for trouble.
One thing I noticed digging through the code though — L4 risk scoring categorizes actions purely by verb. _categorize_action parses the action string for keywords like "read" or "delete" but never looks at params. So read.file targeting /etc/shadow gets a risk score of 1, while delete.file on /tmp/cache.json scores 7. In real agent workloads the target matters as much as the verb — feels like the policy engine could bridge this gap with param-aware rules, since the condition evaluator already supports params.* field resolution.
Also noticed TrustScorer takes a decay_rate in __init__ but never actually applies time-based decay anywhere — trust only changes on interactions. So an agent that was trusted six months ago and went dormant still walks back in with the same score. Small thing but could matter in long-running multi-agent setups.
The MCP rug-pull detection is the standout feature for me. Cross-referencing tool names against their descriptions to catch things like "safe_search" that actually calls exec — haven't seen that anywhere else. With how fast MCP is getting adopted this could get real traction.
The context-aware classification is neat, especially the pipe composition stuff. One thing I keep thinking about though — the scariest exfiltration pattern isn't a single bad command, it's a chain of totally normal ones. Agent reads .env (filesystem_read → allow), writes a script that happens to include those values (project write → allow), then runs it (package_run → allow). Every step looks fine individually. Credentials gone. This is basically the same problem as cross-module vulns in web apps — each component is secure on its own, the exploit lives in the data flow between them. Would be interesting to see some kind of session-level tracking that flags when sensitive reads flow into writes and then executions within the same session. Doesn't need to be heavy — just correlating what was read with what gets written/executed.
There is a gsd-plan-checker that runs before execution, but it only verifies logical completeness — requirement coverage, dependency graphs, context budget. It never looks at what commands will actually run. So if the planner generates something destructive, the plan-checker won't catch it because that's not what it checks for. The gsd-verifier runs after execution, checking whether the goal was achieved, not whether anything bad happened along the way. In /gsd:autonomous this chains across all remaining phases unattended.
The granular permissions fallback in the README only covers safe reads and git ops — but the executor needs way more than that to actually function. Feels like there should be a permission profile scoped to what GSD actually needs without going full skip.