Pre-load Devbox environment in container entrypoints for LLM agents and CI/CD

未关闭
  • 哪里不对？
#2,797 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
go
领域
cli, devtools, infrastructure

调研方向

The issue does not identify implementation files or tests. Start by reading the existing devbox shell, devbox run, and container entrypoint code to understand how the environment is constructed and applied. The requested alternatives span CLI behavior, container startup, and environment export; done means a chosen approach reliably makes the Devbox environment available to non-interactive processes.

由索引模型根据 Issue 内容生成。

描述

feature p3 processed triage
What problem are you trying to solve?

I want to run automated scripts or agents inside a Devbox-managed container where dependencies installed via devbox.json are immediately available in PATH—without requiring an interactive devbox shell session.
Currently, when launching a container (e.g., via devbox run or Docker), the environment variables and PATH modifications from Devbox are not applied unless the process runs inside an interactive Devbox shell. This breaks headless/automated workflows like CI jobs, LLM agents, or background services that need project-specific tools (e.g., go, python, node, custom binaries) available at startup.
Specifically, I'm building agentbox, where an LLM agent runs inside a container and needs immediate access to the project's toolchain to execute, test, or debug code. Having to manually enter devbox shell first defeats the purpose of an autonomous, reproducible environment.

What solution would you like?

Add support for non-interactive environment activation in Devbox containers. Specifically:

  1. devbox shell -c "<command>" (similar to bash -c) or similar flag that executes a command with the full Devbox environment (PATH, env vars, etc.). This is differs from commands from "devbox run" because thery are not defined in the devbox.json file.
  2. Container entrypoint option: Allow specifying a command in devbox.json or via CLI that runs automatically with the environment pre-loaded when the container starts (e.g., devbox container run --entrypoint "my-agent").
  3. Exportable environment script: Generate a shell script (e.g., devbox export-env) that can be sourced in a Dockerfile or entrypoint to initialize the environment for any subsequent command.

This would enable headless automation while preserving Devbox's reproducible dependency management—no need to bake custom images or manually manage PATH.

Alternatives you've considered
  • Manual eval "$(devbox shellenv)" in entrypoint: This works in some cases but adds complexity, requires bash/shell, and isn't officially documented for container use. It also doesn't handle all edge cases (e.g., non-shell processes).
  • Custom Docker images per project: Defeats the purpose of Devbox's dynamic environment management and increases build/maintenance overhead.
  • Wrapper scripts that invoke a command inside something like devox run -- bash or devbox shell -c "command": Limited by the fact that devbox shell is designed for interactive use; non-interactive usage is unreliable or unsupported.
主要语言
Go
星标
12.4k
派生
358
平均合并
17 小时 12 分钟
30 天内合并 PR
31

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

jetify-com/devbox 的其他 Issue

查看 jetify-com/devbox 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。