Let a tool declare its code-card language, instead of keying the code row variant on the literal name run_code

[CNSeniorious000]

A plugin that presents a code-execution tool of its own cannot get the Code row, no matter what presentCall returns.

dsh-client-ui-tool classifies a row from a hardcoded name map:

const TOOL_VARIANTS = { bash: 'bash', read: 'read', grep: 'search', /* … */ run_code: 'code' }
const classifyTool = (toolName) => TOOL_VARIANTS[toolName] ?? 'others'

and the variant === 'code' branch renders CodeBlock with lang: "typescript" hardcoded as well. So the code card is keyed on the wire tool name, not on the call view — run_code's own presentCall already returns { card: 'generic', kind: 'execute', rawInput: args.code }, which carries everything except the language.

Two consequences for a third-party tool:

• it cannot opt in, because run_code is a reserved transport name a plugin may not register or shadow;
• even if it could, the label would read typescript for a non-TypeScript runtime.

This already bites in-tree: dsh-code-runtime declares 'python' as a well-known language, so a Python run_code renders Python source under a typescript label today.

Minimal proposal

Add one optional field to GenericCallView — a language hint that only means anything alongside kind: 'execute':

export interface GenericCallView {
  card: 'generic'
  title: string
  kind?: ToolCallKind
  rawInput?: unknown
  language?: string   // new: grammar hint for the code body, when kind is 'execute'
  // …
}

run_code then returns language: resolveFlavor(peekRuntime).language, and the client picks the variant from the view rather than the name:

const variant = callView?.kind === 'execute' && callView.language !== undefined
  ? 'code'
  : classifyTool(toolName)
// … <CodeBlock code={body} lang={callView.language} />

Backward compatible: TOOL_VARIANTS stays for every other row, run_code keeps its variant either way, and a tool that sends no language is unaffected. CodeBlock already takes lang?: string and treats an unknown grammar as plain text, so no new rendering path is needed.

Why it matters beyond one card

Code Mode is presented as a general shape — the tool registry's mode selects it, CodeSdkLanguage is a union with room to grow, and dsh-code-runtime's seam is explicitly provider-shaped. The row variant is the one place where that generality is pinned to a single name. A tool that owns its own execution surface (a persistent REPL, a different language, a sandboxed runner) can already reuse the whole registry, the pipeline, and tool/code-dispatch for SUBTOOL rows — only the card falls back to the generic row.

Happy to send a PR if the shape looks right.

[denial123789]

The rc.2 source confirms the mismatch and the additive view field looks like the right boundary. I would tighten the contract in four places:

1. Use one language source. resolveFlavor(peekRuntime) currently returns schema text but not the canonical language. Either add language: CodeSdkLanguage to RunCodeFlavor or return { language, flavor }, then have presentCall() consume that same validated result. That prevents schema, SDK, runtime, and card language from becoming four mappings.

2. Require the semantic tuple, not language alone. Select the Code row only for card: "generic" + kind: "execute" + string rawInput + non-empty language. Otherwise preserve the existing name/view fallback. This avoids an unrelated card changing family because it emitted one extra field.

3. Keep the hint presentation-only. It must not choose the runtime, executable, sandbox, policy, tool name, or content type. Unknown grammar ids should retain a bounded banner and use CodeBlock's existing plain-text fallback—never become an arbitrary dynamic-import path.

4. Test the peer matrix and replay. New producer/new client uses the view; old producer/new client keeps the run_code name fallback; new producer/old client ignores the optional field. The field also needs to survive live → settled projection and cold Session replay so a later profile switch cannot relabel an older call.

For legacy run_code with no hint, keeping the current fallback is safer than having the client infer language from its current profile; that profile may not be the runtime that produced the durable call. For a third-party tool, the producer-owned view should be sufficient without touching the reserved name.

I maintain the independent DeepSeek Harness Handbook. I wrote the complete compatibility matrix, illustrative type/presenter change, failure router, and 20 regression gates here: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/plugin-development/tool-code-card-language.md