[BUG]: SandboxedEnvironment(autoescape=True) silently corrupts non-HTML config values in framework/loader/config.py

[jonpspri]

Summary

cpex/framework/loader/config.py (line 73) builds the Jinja env for rendering plugins/config.yaml with autoescape=True:

jinja_env = SandboxedEnvironment(loader=jinja2.BaseLoader(), autoescape=True)
rendered_template = jinja_env.from_string(template).render(env=os.environ)

autoescape=True HTML-encodes &, <, >, " in the rendered output. That is correct for HTML templates and wrong for YAML — any Jinja-rendered value (e.g. {{ env.REDIS_URL }} or any other env var passed through this path) containing those characters is silently corrupted before yaml.safe_load consumes it.

First surfaced in IBM/mcp-context-forge#4605 against the now-removed in-tree copy of this file.

Concrete failure cases

• REDIS_URL=redis://user:p&w@host:6379/0 (password containing &) renders as redis://user:p&w@host:6379/0 → broken URL.
• Any env-sourced TLS cert content, API key, or token containing <, >, ", or & → silently corrupted.
• The corruption is silent: YAML parses successfully, plugin init fails downstream with a confusing error that does not point back at the encoding step.

Affects every Jinja-templated value in plugins/config.yaml, not just redis_url.

Proposed fix

jinja_env = SandboxedEnvironment(loader=jinja2.BaseLoader(), autoescape=False)

autoescape=False is the right default for non-HTML output; YAML's own escaping handles structural characters at the yaml.safe_load layer.

Acceptance criteria

• SandboxedEnvironment constructed with autoescape=False
• Regression test that asserts an env var containing &, <, >, " round-trips through Jinja substitution unchanged

Cross-references

• plugin loader: SandboxedEnvironment(autoescape=True) silently corrupts non-HTML config values IBM/mcp-context-forge#4605 — original report (filed against the in-tree copy before the loader was extracted into cpex)