[frenchie4111]

Adds a set_tab_name ness-control MCP tool so an agent can rename the tab it's running in, and makes a name the user typed by hand permanently final.

The tool

set_tab_name takes only a name. There is no tabId or worktreePath parameter — the target is resolved from the caller's scope (x-harness-terminal-id → resolveCallerScope), so an agent can only ever rename itself. Backed by a new POST /tab-name route on the control server, following the tab-scoped shape of /shells (400 without the header, 404 when it resolves to nothing).

Provenance, in one optional field

TerminalTab gains customLabelSource?: 'agent', present only on agent-set names. That polarity is what makes the migration free: a customLabel with no marker means the user typed it, so every label already persisted on disk reads as user-set and locks agents out — which is the behavior we want, with zero migration code.

terminals/tabRenamed now carries source: 'user' | 'agent':

source	label	result
user	non-empty	sets customLabel, drops the marker — always wins, name is now final
user	empty	drops both fields; deliberately re-opens agent naming, since there's no other UI to unlock it
agent	non-empty	refused when a user-set name exists; otherwise sets both

PanesFSM.renameTab now returns whether the rename applied, so the tool result can tell the agent its rename was refused and to stop retrying. It mirrors the reducer's lock rule explicitly rather than inferring refusal from a no-op dispatch — otherwise an idempotent re-set of the same name would read as a refusal.

Agent names go through a new normalizeTabLabel (trim, clamp to 32 chars, null for empty), applied only on the agent path. Clamping the user's typed input would silently change long-standing rename behavior.

The injected system prompt gains the tool and a paragraph on keeping the name current: set it once you know what the session is about, Title Case and a few words, re-set on a genuine change of focus, don't churn it, and a user-set name is final.

The setting

agentTabNamingEnabled, default on, under Agents → General. It follows browserToolsEnabled rather than the experimental opt-ins: only an explicit false is persisted, so absence means enabled and there's no migration.

Disabling hides the feature rather than rejecting it, matching the conversation-fork precedent — telling an agent about a tool whose only outcome is a rejection wastes a turn. Three layers:

• the bridge filters set_tab_name out of tools/list
• buildClaudeLaunchSettings strips the prompt guidance, now extracted as HARNESS_SYSTEM_PROMPT_TAB_NAMING_SECTION
• POST /tab-name still 403s, as a backstop for a bridge started before the toggle flipped

It's deliberately not in Experimental: it's agent-agnostic, default-on, and gates a cosmetic reversible action. The card says explicitly that it governs agents only and that your own rename always works — "turn this off to protect my tab name" is the plausible misreading, and the per-tab lock already covers that case.

One test pins that stripping the section leaves the surrounding bullet list intact. The section is the tail of a list, so it's interpolated after a single \n and removed with one; getting that wrong leaves a dangling blank line in the prompt.

Two adjacent fixes

Both were pre-existing, but this feature turned them from "inconsistent" into "actively wrong":

• tabTypeChanged dropped customLabel on agent↔chat conversion, because both branches rebuild the tab from scratch. With provenance in play that didn't just lose the name — it also handed naming rights back to the agent, so a user-set name would appear to have been overridden. Now carried across with its marker.
• The mobile tab strip rendered tab.label, ignoring custom names entirely.

Not touched: MobileTerminal.tsx's sessionName={tab.label} looks like a third instance of the same bug but isn't — that value feeds the agent spawn args, not the display.

Verification

npm run typecheck, npx electron-vite build, and npx vitest run (1999 tests) all clean. New tests cover every reducer path, the FSM return value, and the route (applies / refused / clamps / 400 / 404).

The mcp-bridge.js JSON-RPC surface was also exercised directly against a stub control server, since it has no vitest coverage: tools/list advertises set_tab_name with a valid schema, and tools/call returns the right text for a plain rename, a clamped over-long name, a refusal, and a rejected empty name. Re-run with the gate off, the tool drops out of tools/list (27 → 26 tools) and the call surfaces the 403 — so both layers of the setting hold.

Two caveats worth stating plainly. I have not exercised the tool inside a real Ness session — that needs the app rebuilt and restarted, which I can't do from inside a session the restart would kill, so the unverified link is the live app wiring (panesFSM.renameTab reached through the real control server), not the tool or route logic. And I have not seen the new Settings card rendered; it typechecks and builds, and its HotkeyBadge / resolvedHotkeys.renameTab references resolve, but nobody has looked at it.

I also saw a single test failure in one full-suite run that did not reproduce across four subsequent runs and that I could not attribute to these files — the suite emits git cherry-pick conflict noise in passing runs too, so a git-touching test is the likely source. Flagging it rather than claiming the suite is deterministic.

🤖 Generated with Claude Code