Repository navigation
README says the CLI's approval gate is sysknife approve; the CLI approves in-process after its own prompt - #655
Conversation
Closes lacs-project#560 Signed-off-by: YuuGR1337 <yudhatamvan25@gmail.com>
vladimirrott
left a comment
vladimirrott
left a comment
There was a problem hiding this comment.
Thanks for picking up #560, @YuuGR1337. Your note gets the facts right: MCP needs the receipt from sysknife approve, and the CLI gates each step with its own prompt or --yes and approves in-process.
I reviewed 64602925. It changes only README.md, so I read it rather than building anything. scripts/check_evidence_claims.py passes on this head (Published figures match the evidence artifacts.). I could not run markdownlint here; CI will.
One change before merge. The PR adds a correction near the top but leaves the wrong sentence in place, so the README now contradicts itself. Lines 301 and 302 on this head still read:
`sysknife approve <transaction-id>` in your terminal — for the CLI and for MCP
alike, which is why an AI client cannot approve its own plan.
#560 asks for that paragraph to be rewritten instead. Please drop the new block under the tagline and replace the paragraph at README.md:300-304 with the three points from the issue:
- MCP plans need a receipt from
sysknife approvein your terminal. - The standalone CLI uses its own prompt, or
--yesup to--max-risk. - An agent with shell access to your account can drive the CLI on its own, so the daemon's role limits are the boundary in that case.
The third point is the one the README leaves out today, and it is the reason the issue exists (#153 records it as an accepted limitation).
The issue also names docs/introduction.md. Line 71 there says the approval gate "collects your approval: sysknife approve in a terminal". It needs the same split between MCP and the CLI. docs/mcp.md only describes the MCP flow and is correct as it stands.
Your workflow runs are waiting on an approval from me. That part is on my side, not yours.
Replaces the README paragraph that said `sysknife approve` gates the CLI and MCP alike with the three cases: an MCP plan needs a terminal receipt, the standalone CLI uses its own prompt or `--yes` up to `--max-risk`, and an agent with a shell on the account can drive the CLI, so the daemon's role limits are the boundary there. Drops the duplicate note under the tagline, which left the README contradicting itself, and splits the same row in docs/introduction.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UpyrhbDTW1gBwzGAC44GYU
vladimirrott
left a comment
vladimirrott
left a comment
There was a problem hiding this comment.
Approving. Thank you for picking up #560. Your reading of the CLI was right from the start: it gates each step with its own prompt and approves in-process, and never calls sysknife approve.
I made the change I'd asked for myself so this could land in today's release. The note under the tagline is gone, and the paragraph in the README now gives the issue's three cases:
- an MCP plan needs a receipt from
sysknife approvein your terminal - the standalone CLI uses its own prompt or
--yesup to--max-risk - an agent with a shell on your account can drive the CLI itself, so the daemon's role limits (linked to
SECURITY.md, layer 3) are the boundary in that case
docs/introduction.md gets the same split. check_public_claims.sh, markdownlint and the internal link check all pass, including the new SECURITY.md anchor.
Fixes #560