fix(core): rebrand attribution headers and meta prompt introduced by v1.18.4 sync - #117
Merged
Alezander9 merged 1 commit intoJul 24, 2026
Merged
Alezander9 merged 1 commit into
Alezander9 merged 1 commit into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Copy link
Copy Markdown
There was a problem hiding this comment.
2 issues found across 15 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/opencode/src/session/prompt/meta.txt">
<violation number="1" location="packages/opencode/src/session/prompt/meta.txt:10">
P2: Normal coding requests phrased as “Can you fix this?” are second-person, so this instruction directs the model to send the user to the README instead of using its tools to perform the requested task. Restrict the README redirect to direct BrowserCode questions or BrowserCode-specific feature/how-to questions, leaving ordinary requests on the task workflow.</violation>
</file>
<file name="packages/core/src/plugin/provider/nvidia.ts">
<violation number="1" location="packages/core/src/plugin/provider/nvidia.ts:14">
P2: NVIDIA requests now carry the new bcode attribution while still sending `X-BILLING-INVOKE-ORIGIN: OpenCode`, so the fork is identified inconsistently and the billing-origin header phones home the upstream brand. Removing that header keeps the NVIDIA request fully bcode-branded, matching the fork policy documented in `UPSTREAM.md`.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
Sorry, something went wrong.
Comment thread
packages/opencode/src/session/prompt/meta.txt
| https://github.com/anomalyco/opencode | ||
| When the user directly asks about OpenCode (eg. "can OpenCode do...", "does OpenCode have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific OpenCode feature (eg. implement a hook, write a slash command, or install an MCP server), use the WebFetch tool to gather information to answer the question from OpenCode docs. The list of available docs is available at https://opencode.ai/docs | ||
| https://github.com/browser-use/browsercode/issues | ||
| When the user directly asks about BrowserCode (eg. "can BrowserCode do...", "does BrowserCode have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific BrowserCode feature (eg. implement a hook, write a slash command, or install an MCP server), point them at the project README at https://github.com/browser-use/browsercode. BrowserCode is a fork of OpenCode (https://github.com/anomalyco/opencode) — generic OpenCode features are likely still applicable, but BrowserCode-specific features (the browser_execute tool, the harness, cloud integrations) live in the BrowserCode repo. |
Copy link
Copy Markdown
There was a problem hiding this comment.
P2: Normal coding requests phrased as “Can you fix this?” are second-person, so this instruction directs the model to send the user to the README instead of using its tools to perform the requested task. Restrict the README redirect to direct BrowserCode questions or BrowserCode-specific feature/how-to questions, leaving ordinary requests on the task workflow.
Prompt for AI agentsCheck if this issue is valid — if so, understand the root cause and fix it. At packages/opencode/src/session/prompt/meta.txt, line 10:
<comment>Normal coding requests phrased as “Can you fix this?” are second-person, so this instruction directs the model to send the user to the README instead of using its tools to perform the requested task. Restrict the README redirect to direct BrowserCode questions or BrowserCode-specific feature/how-to questions, leaving ordinary requests on the task workflow.</comment>
<file context>
@@ -1,20 +1,20 @@
- https://github.com/anomalyco/opencode
-When the user directly asks about OpenCode (eg. "can OpenCode do...", "does OpenCode have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific OpenCode feature (eg. implement a hook, write a slash command, or install an MCP server), use the WebFetch tool to gather information to answer the question from OpenCode docs. The list of available docs is available at https://opencode.ai/docs
+ https://github.com/browser-use/browsercode/issues
+When the user directly asks about BrowserCode (eg. "can BrowserCode do...", "does BrowserCode have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific BrowserCode feature (eg. implement a hook, write a slash command, or install an MCP server), point them at the project README at https://github.com/browser-use/browsercode. BrowserCode is a fork of OpenCode (https://github.com/anomalyco/opencode) — generic OpenCode features are likely still applicable, but BrowserCode-specific features (the browser_execute tool, the harness, cloud integrations) live in the BrowserCode repo.
# Tone and style
- Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
</file context>
Suggested change
| When the user directly asks about BrowserCode (eg. "can BrowserCode do...", "does BrowserCode have..."), or asks in second person (eg. "are you able...", "can you do..."), or asks how to use a specific BrowserCode feature (eg. implement a hook, write a slash command, or install an MCP server), point them at the project README at https://github.com/browser-use/browsercode. BrowserCode is a fork of OpenCode (https://github.com/anomalyco/opencode) — generic OpenCode features are likely still applicable, but BrowserCode-specific features (the browser_execute tool, the harness, cloud integrations) live in the BrowserCode repo. | |
| When the user directly asks about BrowserCode (eg. "can BrowserCode do...", "does BrowserCode have..."), or asks how to use a specific BrowserCode feature (eg. implement a hook, write a slash command, or install an MCP server), point them at the project README at https://github.com/browser-use/browsercode. BrowserCode is a fork of OpenCode (https://github.com/anomalyco/opencode) — generic OpenCode features are likely still applicable, but BrowserCode-specific features (the browser_execute tool, the harness, cloud integrations) live in the BrowserCode repo. |
Sorry, something went wrong.
Comment thread
packages/core/src/plugin/provider/nvidia.ts
Comment on lines
+14
to
16
| provider.request.headers["HTTP-Referer"] = "https://bcode.sh/" | ||
| provider.request.headers["X-Title"] = "bcode" | ||
| provider.request.headers["X-BILLING-INVOKE-ORIGIN"] ??= "OpenCode" |
Copy link
Copy Markdown
There was a problem hiding this comment.
P2: NVIDIA requests now carry the new bcode attribution while still sending X-BILLING-INVOKE-ORIGIN: OpenCode, so the fork is identified inconsistently and the billing-origin header phones home the upstream brand. Removing that header keeps the NVIDIA request fully bcode-branded, matching the fork policy documented in UPSTREAM.md.
Prompt for AI agentsCheck if this issue is valid — if so, understand the root cause and fix it. At packages/core/src/plugin/provider/nvidia.ts, line 14:
<comment>NVIDIA requests now carry the new bcode attribution while still sending `X-BILLING-INVOKE-ORIGIN: OpenCode`, so the fork is identified inconsistently and the billing-origin header phones home the upstream brand. Removing that header keeps the NVIDIA request fully bcode-branded, matching the fork policy documented in `UPSTREAM.md`.</comment>
<file context>
@@ -11,8 +11,8 @@ export const NvidiaPlugin = define({
evt.provider.update(item.provider.id, (provider) => {
- provider.request.headers["HTTP-Referer"] = "https://opencode.ai/"
- provider.request.headers["X-Title"] = "opencode"
+ provider.request.headers["HTTP-Referer"] = "https://bcode.sh/"
+ provider.request.headers["X-Title"] = "bcode"
provider.request.headers["X-BILLING-INVOKE-ORIGIN"] ??= "OpenCode"
</file context>
Suggested change
| provider.request.headers["HTTP-Referer"] = "https://bcode.sh/" | |
| provider.request.headers["X-Title"] = "bcode" | |
| provider.request.headers["X-BILLING-INVOKE-ORIGIN"] ??= "OpenCode" | |
| provider.request.headers["HTTP-Referer"] = "https://bcode.sh/" | |
| provider.request.headers["X-Title"] = "bcode" |
Sorry, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Post-sync branding audit of the v1.18.4 window (#116) found two surfaces where sync-introduced upstream code violates established fork policy. Stacked on sync/upstream-v1.18.4.
1. Provider attribution headers (7 files + their tests)
Upstream's new v2 provider-plugin architecture (packages/core/src/plugin/provider/) sets attribution headers per provider, architecturally bypassing the provider/provider.ts sites rebranded in PR #12 (those survived the sync intact). A bcode binary was crediting OpenCode for its traffic:
Same rationale as PR #12: attribution is not auth or User-Agent; sending opencode.ai from a bcode binary is impersonation. Red-zone identifiers untouched: openai.ts User-Agent: opencode/<ver> + originator: "opencode" (Codex OAuth provider trust), gitlab.ts/cloudflare-*.ts User-Agents, and plugin/provider/opencode.ts (OpenCode-as-provider, user-initiated) are all left verbatim. provider-opencode.test.ts untouched.
2. New meta.txt system prompt
New in this window (upstream #36122), selected when model.api.id.includes("muse-spark"). Shipped as "You are OpenCode", identified itself as OpenCode, sent feedback to anomalyco/opencode, and instructed the agent to WebFetch opencode.ai/docs when asked about its own features. Rebranded following the default.txt / per-model prompt convention (F7 deeper sweep, PR #63): BrowserCode identity, browser-use/browsercode feedback URL, README pointer with fork acknowledgement.
Also audited, deliberately not changed
Verification
Merge order
#116 → main first, then rebase this onto main (or merge this into the sync branch so #116 carries it — either works, changes are confined to sync-introduced files).
Summary by cubic
Rebranded sync-introduced provider attribution headers and the Muse Spark meta system prompt from OpenCode to BrowserCode/bcode. Prevents opencode.ai attribution from bcode traffic and aligns prompts and links with the fork.
Written for commit 0efdbc7. Summary will update on new commits.