* refactor: centralize toolProtocol configuration checks
- Created src/utils/toolProtocol.ts with getToolProtocolFromSettings() utility
- Replaced all direct vscode.workspace.getConfiguration() calls with centralized utility
- Updated 6 files to use the new utility function
- All tests pass and TypeScript compilation succeeds
* refactor: use isNativeProtocol function from types package
* fix: filter native tools by mode restrictions
Native tools are now filtered based on mode restrictions before being sent to the API, matching the behavior of XML tools. Previously, all native tools were sent to the API regardless of mode, causing the model to attempt using disallowed tools.
Changes:
- Created filterNativeToolsForMode() and filterMcpToolsForMode() utility functions
- Extracted filtering logic from Task.ts into dedicated module
- Applied same filtering approach used for XML tools in system prompt
- Added comprehensive test coverage (10 tests)
Impact:
- Model only sees tools allowed by current mode
- No more failed tool attempts due to mode restrictions
- Consistent behavior between XML and Native protocols
- Better UX with appropriate tool suggestions per mode
* refactor: eliminate repetitive tool checking using group-based approach
- Add getAvailableToolsInGroup() helper to check tools by group instead of individually
- Refactor filterNativeToolsForMode() to reuse getToolsForMode() instead of duplicating logic
- Simplify capabilities.ts by using group-based checks (60% reduction)
- Refactor rules.ts to use group helper (56% reduction)
- Remove debug console.log statements
- Update tests and snapshots
Benefits:
- Eliminates code duplication
- Leverages existing TOOL_GROUPS structure
- More maintainable - new tools in groups work automatically
- All tests passing (26/26)
* fix: add fallback to default mode when mode config not found
Ensures the agent always has functional tools even if:
- A custom mode is deleted while tasks still reference it
- Mode configuration becomes corrupted
- An invalid mode slug is provided
Without this fallback, the agent would have zero tools (not even
ask_followup_question or attempt_completion), completely breaking it.
* refactor(task): wrap initial user message in <feedback> instead of <task> to prevent focus drift after context-management
Rationale: After a successful context-management event, framing the next user block as feedback reduces model focus drift. Mentions parsing already supports <feedback>, and tool flows (attemptCompletion, responses) are aligned. No change to loop/persistence.
* refactor(mentions): drop <task> parsing; standardize on <feedback>; update tests
* Migrate conversation continuity to plugin-side encrypted reasoning items (Responses API)
Summary
We moved continuity off OpenAI servers and now maintain conversation state locally by persisting and replaying encrypted reasoning items. Requests are stateless (store=false) while retaining the performance/caching benefits of the Responses API.
Why
This aligns with how Roo manages context and simplifies our Responses API implementation while keeping all the benefits of continuity, caching, and latency improvements.
What changed
- All OpenAI models now use the Responses API; system instructions are passed via the top-level instructions field; requests include store=false and include=["reasoning.encrypted_content"].
- We persist encrypted reasoning items (type: "reasoning", encrypted_content, optional id) into API history and replay them on subsequent turns.
- Reasoning summaries default to summary: "auto" when supported; text.verbosity only when supported.
- Atomic persistence via safeWriteJson.
Removed
- previous_response_id flows, suppressPreviousResponseId/skipPrevResponseIdOnce, persistGpt5Metadata(), and GPT‑5 response ID metadata in UI messages.
Kept
- taskId and mode metadata for cross-provider features.
Result
- ZDR-friendly, stateless continuity with equal or better performance and a simpler codepath.
* fix(webview): remove unused metadata prop from ReasoningBlock render
* Responses API: retain response id for troubleshooting (not continuity)
Continuity is stateless via encrypted reasoning items that we persist and replay. We now capture the top-level response id in OpenAiNativeHandler and persist the assistant message id into api_conversation_history.json solely for debugging/correlation with provider logs; it is not used for continuity or control flow.
Also: silence request-body debug logging to avoid leaking prompts.
* remove DEPRECATED tests
* chore: remove unused Task types file to satisfy knip CI
* fix(task): properly type cleanConversationHistory and createMessage args in Task to address Dan's review
chore(gpt5): stop persisting instructions/reasoning_summary in UI message metadata
Problem: ui_messages.json was getting bloated with unused or duplicated content (system 'instructions' and 'reasoning_summary') that we do not read back. Root cause: earlier OpenAI Responses API implementation persisted these fields to per-message metadata; however, 'instructions' are already sent as top-level request instructions and 'reasoning_summary' is surfaced live via streaming events. Neither field is consumed from storage. Changes: (1) Task.persistGpt5Metadata now stores only previous_response_id; (2) removed instructions and reasoning_summary from types; (3) updated Zod schema; (4) persistence layer writes messages as-is (no sanitizer); (5) tests green. Impact: smaller ui_messages.json, no runtime behavior change for requests. Migration: old metadata fields will be ignored by schema.
* feat(checkpoints): create checkpoint on user message send
* fix(checkpoints): suppress implicit user-message checkpoint row; keep current checkpoint updated without a chat row
* Fix checkpoint suppression for user messages
- Propagate suppressMessage flag through event chain properly
- Update ChatView to check checkpoint metadata for suppressMessage flag
- Ensure checkpoint messages are created but not rendered when suppressed
- Fix bug where checkpointSave(false) should have been checkpointSave(true)
* fix: only create checkpoint on user message when files have changed
- Changed allowEmpty from true to false in checkpointSave call
- Checkpoints will now only be created when there are actual file changes
- This avoids creating empty commits in the shadow git repository
* test: update checkpoint test to include suppressMessage parameter
- Fixed test expectation to match the new function signature
- saveCheckpoint now expects both allowEmpty and suppressMessage parameters
---------
Co-authored-by: Roo Code <roomote@roocode.com>
Co-authored-by: Hannes Rudolph <hrudolph@gmail.com>
Co-authored-by: Daniel Riccio <ricciodaniel98@gmail.com>
* fix: change default showRooIgnoredFiles to false to hide ignored files
- Changed default value from true to false across all files
- Updated tests to reflect the new default behavior
- This prevents ignored files from appearing in environment details
Fixes#7368
* fix: update tests to match new showRooIgnoredFiles default
* fix: update test expectation to match new showRooIgnoredFiles default value
The PR changed the default value of showRooIgnoredFiles from true to false,
so the test needs to expect false instead of true when calling formatFilesList.
---------
Co-authored-by: Roo Code <roomote@roocode.com>
Co-authored-by: daniel-lxs <ricciodaniel98@gmail.com>
