feat: pass run command

[joe0BAB]

Adds a new docker pass run -- CMD [ARGS...] subcommand to the pass plugin. It scans the current environment for variables whose value is se://NAME, resolves each reference via the secrets-engine daemon (requires Docker Desktop to be running), and execs the child with the resolved environment. Mirrors the workflow of op run from 1Password.

Only values that exactly equal se://NAME are resolved; embedded references pass through unchanged and wildcards are rejected. Unresolvable references fail before exec, so the child never starts with a half-resolved environment. The child's exit code is propagated.

SIGINT, SIGTERM, and SIGHUP delivered to pass run are forwarded to the child instead of killing both via the foreground process group, and pass run waits for the child to exit on its own terms. When the child is killed by a signal, pass run exits 128 + signum instead of -1. On Windows only SIGINT is forwarded.

[docker-agent]

❌ PR Review Failed — The review agent encountered an error and could not complete the review. View logs.

[joe0BAB]

/review

[docker-agent]

Assessment: 🔴 CRITICAL

Note: Verification was inconclusive (verifier returned empty response); findings below are from the drafter with manual line-number validation. Two medium-severity bugs were found in newly added code.

Severity	Finding	Location
🔴 MEDIUM	os.Exit() inside wrapRunEWithSpan drops OTel span & metrics	run.go:105
🔴 MEDIUM	Signal handler registered after child.Start() — child can be orphaned	run.go:85

[docker-agent]

os.Exit() inside wrapRunEWithSpan bypasses OTel span.End() and metrics

command.go wraps every subcommand with wrapRunEWithSpan → withOTEL, which calls defer span.End() and calledMetric() after runE() returns. But when the child exits non-zero, run.go calls os.Exit(childExitCode(exitErr.ProcessState)) directly — bypassing all deferred functions and never returning to the withOTEL wrapper.

Result: every non-zero child exit (the most operationally common case) produces an unclosed OTel span and a missing metric event. Only the success path (child exits 0, RunE returns nil) is correctly instrumented.

Fix: return a sentinel error (or a dedicated exit-code error type) from RunE, let withOTEL complete normally, then call os.Exit in a PersistentPostRunE or via a top-level error handler that runs outside the span wrapper.

[docker-agent]

Signal handler registered after child.Start() — signals in the gap orphan the child

child.Start() is called at line 80, but signal.Notify(sigCh, forwardableSignals()...) is not called until line 85. If SIGINT, SIGTERM, or SIGHUP arrives in that window, Go's default handler terminates the parent immediately. The child process, already running, is reparented to init/PID 1 and continues executing indefinitely — a process and secret leak.

Fix: call signal.Notify before child.Start():

sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, forwardableSignals()...)
defer signal.Stop(sigCh)

if err := child.Start(); err != nil {
    return fmt.Errorf("starting child: %w", err)
}

This eliminates the race entirely.