feat(agents)!: authenticate gh via 1Password#6
Conversation
…edentials (v2.0.0) Replace the host-side devcontainer-gh-config volume (which persisted a long-lived GitHub token indefinitely) with on-demand token injection from 1Password: - Drop the devcontainer-gh-config mount and its chown; Claude config volume stays persisted. - Bundle the 1Password CLI (op) in install.sh. - Add a ghTokenSecretRef option; a /etc/profile.d snippet resolves GH_TOKEN from the 1Password secret reference fresh per shell (no host persistence). No-op when unset/unauthenticated, falling back to gh auth login / GITHUB_TOKEN. - Update README and tests; bump feature to v2.0.0 (removes gh persistence).
Runs 'devcontainer features test' on pull requests and pushes so the agents feature (codex/claude/gh/op + gh-token profile script) is verified in CI, with no local tooling required. Pins actions/checkout to a commit SHA per org policy.
* docs(agents): document gh-via-1Password patterns + launchctl host setup Re-applies the local-vs-headless split that didn't make it into #6, and expands the host setup with launchctl coverage (the practical path for Dock/Spotlight launches and the no-checkout Clone-in-Volume flow): - Pattern A (local, recommended): resolve on host, forward GITHUB_TOKEN via remoteEnv. Documents the op-install/.zshrc/editor-launch gotchas. - launchctl setenv for GUI launches, with relaunch / not-persistent / session-wide caveats and an optional login LaunchAgent. - Pattern B (headless): in-container op read via ghTokenSecretRef + service account. * docs(agents): document only the host-forward gh auth approach Drop the two-pattern framing and the headless/service-account (Pattern B) option; document just the local host-forward GITHUB_TOKEN approach. --------- Co-authored-by: Claude <noreply@anthropic.com>
0xcadams
left a comment
0xcadams
left a comment
There was a problem hiding this comment.
To me, this all is starting to feel like we just made local development more complex for no benefit. I've been using the 1Password integration with gh cli before the devcontainers, and it will prompt every time to use the gh token. Having it only request once feels like a downgrade, since the main threat vector is some script scraping this token out of your env. In this devcontainer it is still persisted in GH_TOKEN on startup for anyone to scrape.
If it's never in env and always requested with op read when needed, we don't have that problem.
I like having the 1Password integration and I like using gh CLI, and I like the spirit of where this is heading, it just seems like we're struggling to make devcontainers useful and secure.
cc @grgbkr
I agree. It feels like we are learning to crawl again. |
3 participants
What
Reworks how the
agentsfeature handles GitHub auth, addressing the review concern on #2 that the old approach persisted a long-livedghtoken on the host indefinitely. Bumpsagentsto v2.0.0.devcontainer-gh-configvolume and itschown. (The Claude config volume stays.)op) — installed ininstall.shstraight from 1Password's official apt repo (with debsig verification).GH_TOKENfrom 1Password per shell — a/etc/profile.d/10-gh-op-token.shsnippet runsop readon a configurable secret reference at shell start, so nothing is written to the host. No-op when unset /opunauthenticated / unresolvable, falling back togh auth loginorGITHUB_TOKEN.ghTokenSecretRefoption (op://vault/item/field)..github/workflows/test.ymlrunningdevcontainer features teston PRs across a matrix of all three features (agents,docker,pnpm). The agents tests assertop --versionand the gh-token profile script.Breaking change
devcontainer-gh-configis gone — existing persistedghlogins won't carry over. ConfigureghTokenSecretRef+ provideOP_SERVICE_ACCOUNT_TOKEN, or fall back togh auth login. Consumers should pin:2.Testing
devcontainer features test(now in CI) covers install + profile script. Theop read → GH_TOKENpath needs a real 1Password service account, so verify it manually in a Codespace/container withOP_SERVICE_ACCOUNT_TOKENset:bash -lc 'gh auth status'.Why direct apt install vs a community
opfeatureThere's no official 1Password devcontainer feature; the community ones (
itsmechlark,duplocloud) are third-party. Since this change is security-motivated and the otherdependsOnentries are all first-party, pullingopfrom 1Password's own signed apt repo is the tighter supply chain.