feat: run-context stamp on approval prompts, notifications, and audit#114
Merged
Conversation
Add agent_sudo/run_context.py: a process-wide stamp (version, install_type, client, workspace, pid) built from the self_identity primitive (#108). The acting process captures it, so the approval-helper (a separate process) shows the requester's identity rather than its own. Wire the three surfaces: - approval prompt: helper prints a 'From:' line from the record's run_context - notification: identity line in the body - audit: stamped once at AuditLogger's write choke point (all entries) Client comes from MCP initialize clientInfo.name; workspace from build_server. ApprovalRequest gains one optional, additive run_context field (older records and external producers deserialize unchanged). No approval-flow or audit-schema redesign beyond this field. Closes #109
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.
Closes #109. Second in the founder-dogfood self-identity chain; builds on the
SelfIdentityprimitive from #108 (#113).Principle: a permission tool must clearly identify which copy of itself is guarding the user. At the trust boundary — an approval prompt — nothing named the asking install. During dogfood this meant a stale copy could prompt anonymously and you had to
ps aux | grepto find out which process was live.What
New
agent_sudo/run_context.py: a process-wide stamp of{version, install_type, client, workspace, pid}, built fromself_identity. Captured by the acting process, so the value stored on an approval record is the requester's identity — which the separate approval-helper process then displays verbatim instead of recomputing its own.Three surfaces, same identity:
From:line:From: agent-sudo 0.5.6 (editable) · client=antigravity · ws=/Volumes/Storage/Agent_Sudo · pid=61771via agent-sudo 0.5.6 (editable)run_contextstamped once atAuditLogger's write choke point, so every record (decisions + approval lifecycle) names its producer.Client comes from MCP
initialize→clientInfo.name(defaults toclifor console-script,unknownotherwise). Workspace is set inbuild_server.Scope discipline
ApprovalRequestgains one optional, additiverun_contextfield — older records and external producers deserialize unchanged;to_dictomits it when absent.Tests / validation
tests/test_run_context.py(12 cases): field shape, client/workspace resolution, stamp formatting, audit stamping, approval-record round-trip + legacy-record tolerance.ruffclean.security_model.mdnotes the additiverun_contextblock.