[FEATURE]: allow shell commands in the frontmatter #5082

Activity

1. rwese

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Dec 4, 2025
2. github-actions commented on Dec 4, 2025

   

   github-actionsBot

   on Dec 4, 2025 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: {env:MY_VAR} support in agent yaml #5054: [{env:MY_VAR} support in agent yaml] - Requests environment variable substitution support in agent YAML files
   • Custom environment variables when running commands #718: [Custom environment variables when running commands] - Requests ability to set custom environment variables for command execution
   • [FEATURE]: custom model aliases #3439: [custom model aliases] - Similar concept of dynamic model selection without editing files, proposes using aliases
   • [FEATURE]: Configurable command timeout in config.json #3950: [Configurable command timeout in config.json] - Related feature of environment-based configuration through config files
   • Define opencode cache folder as an Environment variable - OPENCODE_CACHE #2432: [Define opencode cache folder as an Environment variable] - Example of using environment variables for configuration

   The core feature request appears to be dynamic configuration through shell command evaluation in frontmatter, which would enable:

   • Setting different models based on environment variables
   • Cost-based model selection
   • Local vs. remote model switching for testing

   Feel free to ignore if your specific case differs from these existing feature requests.
3. rwese commented on Dec 4, 2025

   

   rwese

   on Dec 4, 2025

   ContributorAuthor

   More actions

   I could adapt it to be as #5054 my thought was to stick with the way the yaml files are currently using shell-commands.

   #3439 would be too abstract for my liking
4. ariane-emory commented on Dec 4, 2025

   

   ariane-emory

   on Dec 4, 2025

   Last edited by ariane-emory

   Contributor

   More actions

   A potentially more efficient alternative might be to employ the same {env:SOME_VAR} / {file:some_file} syntax that is already supported in the opencode.json file.

   Accessing an environment variable is such a trivial task, very many programs (including opencode itself in the JSON context used for the config) can just read environment variables directly without needing to start up a whole new shell in order to do it.

   The code that opencode uses to do this in the configuration file can be found in packages/opencode/src/config/config.ts somewhere near line ~725 or so.

   👍React with 👍4Reacted by atkr, shuv, Brian Sunter and Juliusz Ćwiąkalski
5. ariane-emory commented on Dec 4, 2025

   

   ariane-emory

   on Dec 4, 2025

   Contributor

   More actions

   Actually, we probably only want the f(env:SOME_VAR} syntax for MD frontmatter, the {file:some_file} syntax doesn't seem like it would be terribly useful in the context of frontmatter.
6. rekram1-node

   self-assigned this

   on Dec 13, 2025
7. Toady00 commented on Mar 1, 2026

   

   Toady00

   on Mar 1, 2026

   More actions

   Adding another use case: I’m looking for actual shell command execution in frontmatter, not just variable substitution.

   I keep a small YAML config file per repo to inform the agent about repo-specific details (e.g. where my specs directory is, other project paths, etc). I use yq to pull values out of that YAML and inject them into command markdown so the agent knows where to go look for things. I use this pattern pretty broadly.

   One specific thing I’d like to drive from that same repo config is model selection per project. The goal is to keep command files generic/portable and avoid editing them per repo, while still letting each repo say "use model X for this project".

   I could do this with env vars, but that tends to add more setup and tooling (direnv, docs, onboarding steps). Especially when collaborating, it’s much simpler if the repo just carries a YAML config and commands can read it directly.

   So this feature would unlock a clean repo-config-controls-behavior pattern, not just templating convenience.
8. github-actions commented on May 1, 2026

   

   github-actionsBot

   on May 1, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as not plannedon May 1, 2026