fix(agent): lock stops the agent promptly; calmer mlock note - #132
Merged
Conversation
Two rough edges found during hands-on testing:
1. `pass-cli lock` left a locked-but-running agent for up to one expiry tick
(~30s): the socket kept answering, so commands hit "agent is locked" with no
fallback, AND `pass-cli agent` refused to restart ("already running"). There
is no in-place re-unlock by design. Fix (owner-chosen model): the server now
stops as soon as a request leaves the agent locked (explicit lock/shutdown, or
idle/max-TTL enforcement during a request), freeing the socket. Commands then
fall back to direct-open and a fresh `pass-cli agent` can rebind. lock help +
MethodLock doc updated to say it stops the agent.
2. The mlock failure warning was alarming and misleading ("could not harden agent
memory ... continuing without mlock") even though PR_SET_DUMPABLE=0 succeeded.
Reworded to a calm note that states core-dump/ptrace protection is active and
only the swap-lock is unavailable (expected without a raised RLIMIT_MEMLOCK).
Tests: TestServer_LockStopsServerPromptly (unit — server stops on lock) and
TestIntegration_Agent_LockThenFallback (socket freed + exec falls back to
direct-open with the password on stdin). Full agent + integration suites green;
golangci-lint 0 issues on linux and darwin.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014kVLjbUL4F4CkoA7RbMYy8
Testing showed the natural reach is 'pass-cli agent lock' (next to 'agent stop'
/'agent status'), not the top-level 'pass-cli lock'. Register lock under 'agent'
too, sharing one run function; keep the top-level shortcut as well. Also handle
ErrNoAgent gracefully ('no agent is running (nothing to lock)') instead of
surfacing a raw error. Integration test now drives 'agent lock' end-to-end.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014kVLjbUL4F4CkoA7RbMYy8
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.
Two rough edges found during hands-on testing of the agent.
1. `lock` left a locked-but-running agent (~30s dead window)
After `pass-cli lock`, the agent zeroed its secrets but kept running until the next expiry tick. During that window:
There is no in-place re-unlock by design. Per the owner-chosen model, the server now stops as soon as a request leaves the agent locked (explicit `lock`/shutdown, or idle/max-TTL enforcement during a request), freeing the socket. Commands then fall back to direct-open, and a fresh `pass-cli agent` can rebind. `lock` help + the `MethodLock` doc now say it stops the agent; unlock = run `pass-cli agent` again.
2. Alarming/misleading mlock warning
`Warning: could not harden agent memory ... continuing without mlock` fired for every interactive user (default 8 MB `RLIMIT_MEMLOCK` < a Go runtime), and wrongly implied no hardening — even though `PR_SET_DUMPABLE=0` had already succeeded. Reworded to a calm note: memory not locked into RAM, core-dump/ptrace protection still active, raise `RLIMIT_MEMLOCK` (or use the systemd unit) to enable mlock.
Tests
🤖 Generated with Claude Code