1. Why Do You NEED This Feature?
I need a per-invocation way to run Forge as a strictly safe review/exploration agent in automation. For code review wrappers, the desired contract is simple: read local repository context, produce an answer, and do not write files, run shell commands, or fetch network content unless those capabilities are explicitly allowed.
This matters because multi-agent review systems need to prove each tool's boundary before running it on untrusted or sensitive code. If a selected Forge agent may have network/tool capability enabled, conservative wrappers must either skip Forge or grant broader access than intended.
2. What Is NOT Possible Right Now?
I cannot reliably run one Forge prompt with an explicit, auditable boundary such as "no tools", "read-only", or "no network" and verify the effective capability set in a machine-readable way.
Desired examples:
forge -p "Review this diff" --no-tools
forge -p "Review this diff" --read-only
forge -p "Review this diff" --disable-network
forge -p "Review this diff" --deny fetch
forge list tools --agent sage --porcelain
Read-oriented agents are useful, but wrappers still need a per-run guarantee and/or a machine-readable capability report covering filesystem writes, shell execution, and network fetch.
3. What WILL Be Possible With This Feature?
Automation could safely include Forge in review lanes without silently broadening the trust boundary. For example:
forge -p "Review this diff for correctness" --agent sage --read-only --disable-network --output-format json
A wrapper could then know that this invocation cannot write files, run shell commands, or fetch URLs.
Proposed Solution (User Experience)
Add per-invocation controls such as:
--no-tools
--read-only
--disable-network
--deny <tool-or-capability>
Also provide a machine-readable way to inspect the final effective capability set for an agent/run, for example through forge list tools --agent <id> --porcelain or an --explain-capabilities flag.
Alternatives Considered
Wrappers can skip Forge when network/tool capabilities are detected, or allow those capabilities globally. Skipping reduces review coverage; allowing broader access weakens the safety contract for code review automation.
Feature Category
Security
Priority/Impact
High - Would significantly improve my workflow
Examples from Other Tools
Other CLI agents expose non-interactive modes with sandbox/read-only/no-network style switches or machine-readable execution metadata. The exact design can be Forge-specific; the key requirement is an auditable per-run boundary.
Additional Context
Related issues/epics mention permission and mode boundaries, but this request is specifically for prompt-mode automation: per-invocation read-only/no-network/no-tools controls plus machine-readable verification.
Pre-submission Checklist
1. Why Do You NEED This Feature?
I need a per-invocation way to run Forge as a strictly safe review/exploration agent in automation. For code review wrappers, the desired contract is simple: read local repository context, produce an answer, and do not write files, run shell commands, or fetch network content unless those capabilities are explicitly allowed.
This matters because multi-agent review systems need to prove each tool's boundary before running it on untrusted or sensitive code. If a selected Forge agent may have network/tool capability enabled, conservative wrappers must either skip Forge or grant broader access than intended.
2. What Is NOT Possible Right Now?
I cannot reliably run one Forge prompt with an explicit, auditable boundary such as "no tools", "read-only", or "no network" and verify the effective capability set in a machine-readable way.
Desired examples:
Read-oriented agents are useful, but wrappers still need a per-run guarantee and/or a machine-readable capability report covering filesystem writes, shell execution, and network fetch.
3. What WILL Be Possible With This Feature?
Automation could safely include Forge in review lanes without silently broadening the trust boundary. For example:
forge -p "Review this diff for correctness" --agent sage --read-only --disable-network --output-format jsonA wrapper could then know that this invocation cannot write files, run shell commands, or fetch URLs.
Proposed Solution (User Experience)
Add per-invocation controls such as:
Also provide a machine-readable way to inspect the final effective capability set for an agent/run, for example through
forge list tools --agent <id> --porcelainor an--explain-capabilitiesflag.Alternatives Considered
Wrappers can skip Forge when network/tool capabilities are detected, or allow those capabilities globally. Skipping reduces review coverage; allowing broader access weakens the safety contract for code review automation.
Feature Category
Security
Priority/Impact
High - Would significantly improve my workflow
Examples from Other Tools
Other CLI agents expose non-interactive modes with sandbox/read-only/no-network style switches or machine-readable execution metadata. The exact design can be Forge-specific; the key requirement is an auditable per-run boundary.
Additional Context
Related issues/epics mention permission and mode boundaries, but this request is specifically for prompt-mode automation: per-invocation read-only/no-network/no-tools controls plus machine-readable verification.
Pre-submission Checklist