feat: add tapes auth and credential injection for agents#98
Conversation
Add credential storage and auto-injection so users don't need to manually set API keys in their shell before launching agents.
…rface errors Move codex auth.json helpers into pkg/credentials for reuse, remove permanent ~/.codex/auth.json modification from tapes auth, add sk-proj- key format warning, surface swallowed errors in injectCredentials, and add test coverage for credential injection.
|
Documentation updated for this PR. Docs PR: https://github.com/papercomputeco/tapes.dev/pull/51 Changes include:
|
jpmcb
left a comment
jpmcb
left a comment
There was a problem hiding this comment.
Nice work: just a few comments
| golang.org/x/sync v0.17.0 // indirect | ||
| golang.org/x/sys v0.37.0 // indirect | ||
| golang.org/x/sys v0.41.0 // indirect | ||
| golang.org/x/term v0.40.0 // indirect |
There was a problem hiding this comment.
Looks like you had a dirty go mod: you need to run go mod tidy before pushing although I honestly haven't been the best about this either.
I created a new dagger module that runs in CI to check we have a clean go mod during PR!
| if err := os.WriteFile(m.targetPath, buf.Bytes(), 0o600); err != nil { | ||
| return fmt.Errorf("writing credentials: %w", err) | ||
| } |
There was a problem hiding this comment.
Nice work on this: 0600 file perms is the main thing I was looking for since dropping plain text creds readable / usable by the rest of the system would be a problem.
We might also consider aligning on XDG_CONFIG_HOME and putting these in ~/.config/tapes vs in the user's home at ~/.tapes by default. I suppose it's up to us since ~/.aws/ is definitely a thing - just depends on if we want to scatter configs on the user's home directory or in ~/.config/.
I know that some tools, like GitHub's gh have started using the native password/security tooling on the system (MacOS keychain, GNOME Keyring, KDE Wallet, etc.) but are much more challenging to implement in a headless server setting. We may consider adopting those as defaults for tapes but this works for now!
We could also consider implementing shelling into the 1password CLI to resolve op:// secrets like:
version = 0
[providers]
[providers.openai]
api_key = "op://Engineering/openai-key"that can evaluate then evaluate to a vault.
2 participants
Summary
tapes auth <provider>command to store API credentials in~/.tapes/credentials.tomltapes start~/.codex/auth.jsonwith the stored key on launch and restores the original on exit — so runningcodexdirectly still uses the Codex plan (OAuth)close #88
DX Discoveries
During implementation we found that codex ignores
OPENAI_API_KEYenv vars when OAuth tokens exist in~/.codex/auth.json. The OAuth tokens are scoped for ChatGPT's internal API (/api/codex/) and lack theapi.responses.writescope needed for the public/v1/responsesendpoint that the tapes proxy routes to.Additionally, personal project keys (
sk-proj-) from OpenAI may lack required API scopes even with "All" permissions selected. Service account keys (sk-svcacct-) are required for codex proxy telemetry. The auth command messaging guides users toward this.Usage
Test plan
go test ./pkg/credentials/...— 20 specs passgo test ./cmd/tapes/auth/...— 10 specs passmake format— lint cleantapes auth openai→tapes start codex→ verify telemetry capturedcodexdirectly still uses OAuthContinue Tasks: ✅ 3 no changes — View all