flue

Every repo that uses flue workflows with a sandbox currently needs to copy-paste the same ~40 lines of GitHub Actions YAML: checkout, docker login, buildx setup, build-push with caching and GHCR tagging. It's entirely generic except for the Dockerfile path and image name. When we improve the build (e.g. add multi-platform support, change caching strategy, or update pinned action versions), every repo needs to be updated independently. Should we consider publishing a reusable composite GitHub Action that encapsulates this? The action would enforce conventions by default (Dockerfile at , image pushed to ) but allow overrides via inputs. A consumer's workflow would shrink to: Inputs like , , and would be available for repos that need to customize. The path trigger () has to stay in the consumer's workflow since that's workflow-level config GitHub Actions can't encapsulate, but everything inside the job becomes a single line.

In the Astro repo, we still have a need to run privileged CLI calls from inside the restricted sandbox (with sandbox mode enabled). This is impossible because the sandbox is untrusted, so we can't pass privileged tokens into the sandbox and the sandbox cannot call back out to the host. Should we consider an optional MCP tool to the container via host-side MCP server. Workflow authors declare a policy of allowed commands via , and the LLM inside the container is then able to call a MCP tool that tunnels the command back to the host for execution. The host enforces the allowlist, rate limits, and per-command environment variables — the container never sees the actual tokens. This keeps the security model honest: the policy is set by the workflow, and anything not explicitly allowed is denied. Alternatively, should we consider a proxy system that allows the LLM to speak to services? without ever seeing the tokens that access them. This would bring more flexibility and fewer restrictions to how the LLM talks to these services, but also greater risk that it could be misused/exploited. A surprise benefit: this would unlock supporting more LLM providers than just Anthropic, and our current anthropic proxy could move to this public API.