Feature request: rtk wrapper for 1Password CLI (op item / op read / op vault)
#1.737 geöffnet am 6. Mai 2026
Repository-Metriken
- Stars
- (48.085 Stars)
- PR-Merge-Metriken
- (Durchschn. Merge 11T 1h) (45 gemergte PRs in 30 T)
Beschreibung
Use case
The 1Password CLI (op) is a high-frequency command in security-sensitive workflows where developers retrieve secrets at runtime via op:// references. Currently op calls bypass rtk (no wrapper exists), missing both invocation tracking and output filtering.
Frequency observed
From a single dev workstation running rtk discover (rtk 0.38.0):
TOP UNHANDLED COMMANDS
─────────────────────────────────────────
op read 194× VTOKEN=$(op read "op://HQ-Dev/yonatan-hq-dev/...")
op item 185× op item list --vault HQ-Dev
─────────────────────────────────────────
379× combined, no rtk handle
op ranks above pgrep, grep and others that already have wrappers.
Suggested filter shape
| Subcommand | Filtering opportunity |
|---|---|
op item list |
Table compaction (strip ANSI, header rows) |
op item get |
JSON keys-only by default (--keys-only-style); full output with -v |
op item create |
Strip preamble + show only {id, title, vault} |
op vault list |
Compact table |
op read |
Already returns just the secret value — minimal output filtering, but track invocations for adoption telemetry and rtk discover |
op signin / op whoami |
Pass-through with brief status |
Sensitivity considerations
op readoutput IS the secret. Filter must NEVER cache or log the value —teemode should be disabled for op subcommands by default, or selectively skipped.- Existing rtk filters strip nothing from secret-bearing positions; this wrapper would need explicit
tee_disabled = truesemantics.
Why not exclude_commands?
op is opted-in to rtk: developers WANT the invocation tracking (compliance, audit, knowing which env vars resolve from which vault). They just don't want output captured.
Telemetry impact
Adoption from our session: ~22-58% of commands route through rtk; the unhandled op invocations are a meaningful slice of the gap.
cc: this came out of an audit prompted by the pytest -q summary regression we hit in 0.28.2 (fixed in 0.36.0 commit 57502a5 — thanks). After upgrading to 0.38.0, rtk discover surfaced this as the next highest-leverage gap.