fix(server): rebuild agent session when chat/agent mode changes (#1767)

[ZhYGuoL (ZhYGuoL)]

Switching between Chat and Agent mode mid-conversation had no effect. The assistant kept answering that it was in Chat mode and kept refusing browser automation.

The client sends the mode correctly on every turn. The problem is server side: an agent's toolset and system prompt are built once, when the session is created, and the session is cached per conversation. ChatService already rebuilds that session when MCP servers or the workspace change mid-conversation, but not when the mode changes. So a conversation that started in Chat mode kept its read-only toolset and its "you are in read-only chat mode" system prompt (prompt.ts) for the rest of the conversation, and the toggle did nothing.

This is not new-tab specific, despite the report. The sidepanel behaves the same way if you send a message before switching. The new tab page just makes it easy to hit, since its first turn is usually a plain question.

What changed

• session-store.ts: track chatMode on AgentSession, alongside the existing mcpServerKey and workingDir change-detection fields. Declared required rather than optional so the compiler enforces the stamp: an unstamped session would compare undefined !== false and fake a mode change on the first turn.
• chat-service.ts: rebuild the session when chatMode changes mid-conversation, matching the existing MCP and workspace rebuild paths.

Scope, and why it is drawn here

• Both directions rebuild. Only chat -> agent was reported, and it is the safe one: agent's toolset is a superset of chat's, so that rebuild re-admits tools and strips nothing. But rebuilding only that direction would leave chat -> agent -> chat holding full write tools while the toggle reads chat, which is a worse failure than the one being fixed.
• Known tradeoff. agent -> chat narrows the toolset, so sanitizeMessagesForToolset drops the agent's record of tool calls it already made, and switching back does not restore them. The MCP and workspace rebuilds already behave this way. It costs the agent context, not the user's chat history, which is stored client-side.
• ACP-backed providers are excluded on purpose. A rebuild cannot deliver a mode change to them: their instructions live in the workspace instruction file, and ensureWorkspaceInstructionFile() skips with skipped-not-new-conversation whenever isNewConversation is false, which it is on every rebuild since it comes from !session evaluated beforehand. Rebuilding would hand the agent a fresh in-band prompt contradicting the stale on-disk block. Mode switching for ACP needs that file refreshed mid-conversation, which seems worth its own change and its own decision. Happy to take direction.

How I verified

The regression test fails on main before the fix:

$ bun test tests/api/services/chat-service.test.ts -t "switches from chat to agent"
expect(createCalls).toHaveLength(2)
Expected length: 2
Received length: 1
(fail) rebuilds the session when the user switches from chat to agent

and passes after:

$ cd apps/server && bun test tests/api/services/chat-service.test.ts
 15 pass  0 fail

$ cd apps/app && bun run test
 311 pass  0 fail

$ cd apps/server && bun run typecheck
 Exited with code 0

$ bunx @biomejs/biome check <changed files>
 Checked 3 files. No fixes applied.

Tests added: rebuilds the session when the user switches from chat to agent, re-restricts the session when switching back to chat mode, leaves ACP sessions alone on a mode switch, does not rebuild the session when the mode is unchanged.

Notes for reviewers

While tracing this I found two adjacent things that are out of scope here but may be worth separate issues:

• Read-only chat mode is not enforced for ACP providers (claude-code, codex, acp-custom), only suggested via the prompt. buildAcpMcpServers / buildBrowserOsSelfMcpEntry send no mode to /mcp, so that surface stays fully writable. An agent that ignores the instruction can still click and navigate while the user believes they have restricted it.
• autoAttachActiveTab (chat-actions.hooks.ts) is dead config: useChatActions has one caller and it never passes the flag, and the sidepanel does not use the hook at all.

Fixes #1767.

[github-actions]

All contributors have signed the CLA. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[ZhYGuoL (ZhYGuoL)]

I have read the CLA Document and I hereby sign the CLA

[Dani Akash (DaniAkash)]

Greptile (@greptileai)

[greptile-apps]

Greptile Summary

The PR rebuilds cached non-ACP agent sessions when chat/agent mode changes.

• Stamps each session with its creation-time chat mode.
• Reconciles mode, workspace, and MCP changes through a single rebuild.
• Adds model-visible transition notices and regression coverage for mode switching.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains within the scope of the previous review thread.

Important Files Changed

Filename	Overview
packages/browseros-agent/apps/server/src/agent/session-store.ts	Adds the required chat-mode stamp used to detect configuration drift in cached sessions.
packages/browseros-agent/apps/server/src/api/services/chat-service.helpers.ts	Extracts pure builders for MCP, workspace, and mode-change notices.
packages/browseros-agent/apps/server/src/api/services/chat-service.ts	Snapshots cached session inputs, performs one rebuild for relevant non-ACP changes, and emits each applicable notice.
packages/browseros-agent/apps/server/tests/api/services/chat-service.helpers.test.ts	Covers all notice-builder variants.
packages/browseros-agent/apps/server/tests/api/services/chat-service.test.ts	Covers bidirectional mode changes, unchanged modes, ACP exclusion, and simultaneous session-input changes.

_{Reviews (2): Last reviewed commit: "refactor(server): replace rebuiltThisTur..." | Re-trigger Greptile}

[Dani Akash (DaniAkash)]

Greptile (@greptileai)