Hard-coded response language injected into the system prompt, with no setting to change it

[tatarskii]

Summary

Every conversation gets a hard-coded language instruction injected into the system prompt:

Language

Respond in English. This applies to any visible reasoning or thinking text as much as to the answer itself: do not drift into another language mid-conversation, even when earlier context, file contents, or prior turns contain other languages. Only when the user explicitly asks for another language - a translation, or a request to answer in a specific language - follow their request.

There is no setting anywhere - CLI, desktop app, config file, or env var - to change this language or to disable the injection.

Why this is a problem

• Non-English users have to re-convince the agent to answer in their language in every conversation. Because a system-prompt instruction outranks user messages, the agent frequently still answers in English, or drifts back to it mid-session despite being asked otherwise.
• Even when persuasion works, it costs extra tokens and friction on every single session ("please respond in Russian", "I asked you to answer in Russian", ...).
• Thinking text is forced into English too, so even the model's visible reasoning leaks English into an otherwise non-English workflow.
• Language is purely a user preference. Modern models mirror the user's language just fine when left alone; baking a fixed value into the system prompt with no override makes the product genuinely painful for anyone whose primary language isn't English.

Suggested fix

1. Make the injected language user-configurable: a language option in the config file, a /language command in the CLI and desktop app, or an env var.
2. Support an auto (default) mode that removes the injection entirely and lets the agent mirror the user's language naturally.
3. Ensure an explicit in-chat request ("answer in X") always wins over the injected default - right now the injected instruction is what the model treats as authoritative.

This would remove a daily annoyance for every non-English-speaking user with essentially zero downside for English speakers (English remains the default).

[tatarskii]

Follow-up: the override mechanism exists, but there's no safe way to change only the language part

The .agents/templates/ override system (see packages/agent-runtime/src/templates/README.md) lets you override an agent's systemPrompt with append / prepend / replace. In theory that should solve this, but in practice there is no supported way to rewrite just the response-language instruction without touching (and risking) everything else:

1. The injected block isn't in the open-source repo. The # Language section is added server-side before the request hits the model, so its exact text isn't something an override can target. The only operations available are whole-prompt append/prepend/replace — there is no remove/patch that strips a section by header or fragment.
2. replace swaps the entire system prompt. To remove one paragraph you have to reconstruct the whole prompt from scratch: orchestration rules, spawnable agents, response examples, placeholders like {CODEBUFF_FILE_TREE_PROMPT_SMALL}... Miss any of them and you silently degrade agent behavior, and there's no render of the current effective prompt to start from. It's also undocumented which agent id to target (the README shows "CodebuffAI/reviewer"; for the main agent I had to guess CodebuffAI/base2).
3. append/prepend can't cancel the injection. A system prompt that still says "Respond in English" plus an appended "reply in Russian" leaves the model with two authoritative-but-conflicting instructions. Results are inconsistent: it works for a few turns, then drifts back to English mid-session.

I hit exactly this: to get responses in my language I had to write a full replace override for base2 and hope I hadn't broken anything else in the prompt. That's a lot of risk for what is a one-line preference.

Suggestions that would fix this class of problem:

• Make response language a first-class setting (config file / /language command / env var), with an auto default that skips the injection entirely — this is the clean fix;
• or support a remove-style prompt override that strips a section by header/fragment, so users can surgically edit prompts they can't see rendered;
• and/or a --print-system-prompt debug flag so users can see the final assembled prompt (including server-side injections) before overriding it.

[tatarskii]

Update: per-agent overrides are clunky — and even they don't fully work

Following up on my previous comment. I built the replace override described there, with a strict, unambiguous policy ("Respond in Russian — always and unconditionally... never respond in English, Chinese, or any other language, even if the user's message arrives translated by a proxy in transit"). Two findings from actually using it:

1. The override system is one-file-per-agent, with no global scope.

Overrides are keyed by exact agent id ("type": "CodebuffAI/base2"). There's no wildcard, no user-level policy, no inheritance to subagents. In practice that meant:

• the same language policy had to be duplicated into 4 files to cover just the main orchestrator across model variants: base2, base2-free-glm, base2-free-glm-5-3-flash, base3-free-glm-5-3-flash;
• covering the subagents that actually write most of the text (editor, code-reviewer, basher, thinker, and every future model variant of them) would mean a growing pile of near-identical files;
• any new agent or model variant silently falls outside the policy — you find out because it answers in the wrong language.

A one-line user preference turns into N maintained files.

2. Even with all four overrides in place, replies still come in English.

The strict Russian policy does not reliably win over whatever is injecting/forcing English downstream. It's also impossible to debug why: there is no feedback about whether an override file actually matched an agent id (wrong guess in "type" = silent no-op), and no way to view the final assembled prompt to check whether the override and the English injection are both present.

This strengthens the original point: language must be a first-class client setting (language: "ru" or "auto" in config, applied once above every agent), not something each user re-implements per agent with template overrides. Concretely useful steps in the meantime:

• a wildcard/global override scope (e.g. "type": "*" or a user-level policy file) so one file can cover all agents;
• or automatic inheritance: subagents inherit the parent's language policy;
• a visible warning/log when an override file exists but matches no agent id;
• and --print-system-prompt to see what actually reaches the model.

[zhorikbro21]

I can reproduce this on Freebuff Desktop 0.0.93 on Windows 10.

My global and project-level AGENTS.md files explicitly require all responses, progress messages, and tool-use commentary to be in Russian, and injectAgentsMd is enabled. The local orchestrator confirms that these files are discovered and injected, yet the agent still intermittently switches to English, including in the middle of a live tool-use transcript.

The local base prompt does not contain the reported “Respond in English” instruction, which suggests that it is added by another prompt layer, possibly the server-side harness.

Please expose a configurable response-language setting or ensure that explicit language preferences from AGENTS.md always override the default instruction. A regression test should cover tool calls, progress messages, and new threads.