fix: token substitution in OPENCODE_CONFIG_CONTENT

[ariane-emory]

What does this PR do?

• Route inline config through load() function to enable {env:} and {file:} token substitution
• Make OPENCODE_CONFIG_CONTENT a dynamic getter for runtime env var access
• Add tests for {env:} and {file:} token substitution in OPENCODE_CONFIG_CONTENT

Fixes #13219

How did you verify your code works?

Manual testing, bun typecheck, bun test.

You may manually test by running commands akin to the following (assuming bash):

echo "matrix" > /tmp/test-secret.txt 
export MODEL="opencode/big-pickle"
OPENCODE_CONFIG_CONTENT='{"$schema":"https://opencode.ai/config.json","theme":"{file:/tmp/test-secret.txt}", "model":"{env:MODEL}"}' bun dev```

[github-actions]

Hey! Your PR title Fix OPENCODE_CONFIG_CONTENT token substitution doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found

PR #13226: fix(config): apply token substitution for OPENCODE_CONFIG_CONTENT

This PR appears to be addressing the exact same issue as PR #13241. Both are:

• Fixing token substitution in OPENCODE_CONFIG_CONTENT
• Implementing {env:} and {file:} token substitution
• Related to the same underlying problem (issue OPENCODE_CONFIG_CONTENT bypasses {env:} and {file:} token substitution #13219)

You should review PR #13226 to determine if it's already solving this problem or if there are differences in the approach.

[rekram1-node]

/review

[github-actions]

lgtm

[rekram1-node]

did u change to process.env for testing purposes?

Also I would prefer not doing this path.join ("") thing. I get why it works but instead we should probably make:

• load accept either a config file or a directory path (using an object param)
• make laod only accept directory paths so it doesnt run path.dirname internally

This would just make things more clear for the future cause it feels like easy footgun as is rn

[ariane-emory]

@rekram1-node Yes, the switch to using process.env was indeed to facilitate the testing.

I adjusted the load function to take an object as an argument and hoisted out the path.dirname call so that it happens outside of the load function itself. I feel like this makes the changes a little bit messier, and it certainly makes the size of the diff larger: in the prior version, the substantive part of the fix was a single line change, in this version a couple of dozen lines are changed to achieve the same effect.

The functionality doesn't seem to have been impacted, though: the changes do continue to achieve the intended result (the sample test commands in the initial comment still works they did in the prior incarnation of the PR).

For comparison's sake, the original version of the PR can be seen at ariane-emory#163.

What do you think? If you're happier with it this way, then I'll happily bow to your wisdom.

[ariane-emory]

@rekram1-node An alternative take that takes a middle path by adding some explanatory comments to the earlier version of this PR, mitigating the foot gun while retaining the simplicity of the earlier version if thus PR, can be seen here: ariane-emory#164.

Please just let me know take on the issue you like best. :)