Repository navigation
feat(lead): a grant that lasts until the lead session ends, bound to its process - #109
Merged
Merged
Conversation
…its process A grant with expiresAt: null needs lead.procStart (the OS-reported start time of the lead process) and is only valid while that pid is alive AND still has that start time, so a reused pid cannot inherit it. Unreadable start time fails closed with its own reason. 'opencode lead set' now defaults to the session length (--ttl 8h etc. still work, max 24h for timed grants); show/verify/frame say 'until the lead session ends'. Proved against real processes, including a simulated pid reuse; five guards mutation-checked. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
This PR doesn't fully meet our contributing guidelines and PR template. What needs to be fixed:
Please edit this PR description to address the above within 2 hours, or it will be automatically closed. If you believe this was flagged incorrectly, please let a maintainer know. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The operator wants the lead grant for the rest of a working session, not a fixed number of minutes. A bare 'no expiry' is unsafe: the OS reuses pids, so a stale grant could silently authorise an unrelated process days later.
What
expiresAt: nullmeans until the lead session ends, and is only accepted together withlead.procStart, the start time the OS reports for the lead process.opencode lead setnow defaults to the session length (--ttl session). Timed grants still work (--ttl 8h, max 24h) and are bound to the process too when it can be read.show,verifyand the message frame say until the lead session ends.ps -o lstart=on unix, CIM on Windows (not exercised on Windows here).Evidence
Verified live first: against real sessions the whole cycle works (generic frame, grant, lead-directive frame, revoke, generic frame again). This change was proved against real processes, including a simulated pid reuse. Typecheck clean. 444 pass, 8 skip, 0 fail across peer, policy, peers and unattended suites;
fork:verifyclean. Five guards mutation-checked, each red when removed (one of them overlaps with the next line of code, so its test pins the reason message, which is all that check is for).Limits
Process identity is a same-user, same-machine check, as the rest of the lead grant: it defeats pid reuse and stale grants, not a hostile local user. The Windows start-time path is untested. The CLI refusal when the start time is unreadable has no test (needs a real process listing failure).
🤖 Generated with Claude Code