feat: add support for secret environment variables per agent#243
Merged
Conversation
- Introduced a new table `agent_environment_variables` to store encrypted environment variables for each agent. - Implemented CRUD operations for environment variables in the agent repository and service layers. - Added validation for environment variable keys to ensure they are well-formed and not reserved. - Updated agent configuration to include environment variables. - Enhanced API endpoints to manage environment variables, including listing, adding, updating, and deleting. - Updated error handling for environment variable operations.
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
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.
Summary
Adds per-agent secret environment variables, encrypted at rest and injected into the agent's sandbox container at run time. This addresses two related requests: #240 asked for a way to keep secret config (
.env-style values) encrypted, and #241 needs aGITHUB_TOKEN-style credential reachable bygit cloneinside the sandbox — this is the "configuring environment variables directly for the agent container" approach the maintainer described in the #241 discussion.This PR only covers the credential-delivery half of #241 (getting a token into the sandbox so cloning works). The other half — letting the agent review or update an existing pull request — is tracked as a separate follow-up and is not part of this PR, so #241 stays open until that lands too.
Changes
Backend (
services/api)agent_environment_variablestable (migration000017), values encrypted with the existing AES-256-GCMsecret.Encryptor— the same mechanism already used forllm_api_key_secret.agent_mcp_serversslice.^[A-Za-z_][A-Za-z0-9_]*$and can't collide with reserved sandbox-internal variable names (GIT_AUTHOR_*,GIT_COMMITTER_*,OH_SECRET_KEY,OH_EXTRA_PYTHON_PATH,PACA_*), checked case-insensitively so a lowercase lookalike can't bypass it.409(ErrEnvVarKeyTaken) instead of a raw database error."***", even immediately after creation.Runtime (
services/ai-agent)AgentConfignow carries decryptedenv_vars, loaded the same way as the LLM API key. A variable that fails to decrypt is omitted entirely rather than injected as an empty string, so it fails clearly (missing) instead of ambiguously (blank).docker_sandbox()injects them as real container environment variables, so they're usable bygit clone, build tools, and deploy scripts — not scoped to a single MCP server subprocess. Reserved infra vars always win on name collision as defense-in-depth alongside the backend-side validation.Frontend (
apps/web)Test plan
go build ./... && go vet ./... && go test ./...(services/api)pytest(services/ai-agent)tsc -b && biome check . && vitest run && npm run build(apps/web)GITHUB_TOKENvariable on an agent, trigger a private-repo clone, confirm the token reaches the container.Closes #240