release: v6.8.0

[code-crusher]

Summary

Ports the 6.8.2 coding-harness update from the Orbital extension (MatterAIOrg/Orbital-Extension, commit cdb837e) to OrbCode, and bumps the version to 6.8.0.

search_files is now one-shot

• Ripgrep-first with FFF fallback; results bounded to the first 100 matches (default max_results 100).
• Cursor pagination removed from the model-facing schema and output; capped results tell the model to refine the query instead of paginating.

Parallel read-only tool execution

• Leading run of read-only tool calls (read_file, search_files, list_files, list_code_definition_names, codebase_search, lsp) executes concurrently (max 4 workers) with results committed in model order to preserve tool_call/tool_result pairing.
• Mutating and interactive tools stay serialized.

Malformed tool-call recovery

• A tool call with invalid JSON now returns a corrective tool result containing the raw (truncated) arguments plus a re-issue instruction, instead of a bare error.

Strict-mode schema tightening

• Optional parameters are now required with nullable types across all native tool schemas (replace_all, recursive, follow_up, offset/limit, cwd/message/isDangerous, and the CLI-inactive tool schemas).
• execute_command guidance asks for an explicit safety classification.

System prompt

• search_files guidance rewritten for the bounded one-shot behavior.

Test plan

• npm run typecheck passes
• npm run test:search — 11/11 pass
• Remaining node:test suites (attachments, models, plugins, metrics, mcp, files, skills, headers) — 37/37 pass

[matterai-app]

🧪 PR Review is completed: Release PR flipping search_files to a ripgrep-first one-shot model, adding parallel execution of leading read-only tool calls, and tightening tool schemas for strict mode. One real robustness gap in the new parallel batch error path; the rest of the changes look consistent.

Reviewed src/tools/executors/searchFiles.ts: no issues found.
Reviewed src/tools/executors/searchFiles/format.ts: no issues found.
Reviewed src/tools/executors/searchFiles/types.ts: no issues found.
Reviewed src/tools/schemas/search_files.ts: no issues found.
Reviewed src/tools/schemas/execute_command.ts: no issues found.
Reviewed src/prompts/system.ts: no issues found.
Reviewed test/search-files.test.ts: no issues found.

Skipped files

• CHANGELOG.md: Skipped file pattern

⬇️ Low Priority Suggestions (1)

src/core/agent.ts (1 suggestion)

Location: src/core/agent.ts (Lines 1181-1184)

🟡 Concurrency

Issue: handleToolCall is not just tool execution — it also runs PreToolUse/PostToolUse hooks, observeCommittedCode(), and emits tool-start/tool-end events. Running up to 4 of these concurrently means user-defined hooks now fire in parallel and interleave (a hook that mutates state or rewrites inputs is not guaranteed to be concurrency-safe), and UI events for the batch arrive out of model order. This may be acceptable given the read-only restriction, but it's a behavioral change worth confirming the hook runner and TUI event consumers tolerate.

Fix: No code change required if hooks and event consumers are concurrency-safe; otherwise serialize hook execution or document the concurrency guarantee for hook authors.

Impact: Avoids subtle races in user-defined hooks and out-of-order UI event rendering.

-  		if (batchEnd > 1) {
-  			const batch = toolCalls.slice(0, batchEnd)
-  			const results = new Array<string>(batch.length)
-  			let nextIndex = 0
+  

[matterai-app]

🟠 Error Handling

Issue: In the new parallel batch, results are buffered in results[] and only pushed to this.messages after Promise.all resolves. If handleToolCall rejects for any one tool (e.g. an AbortError from user interrupt, or a throwing PreToolUse hook), Promise.all rejects immediately: the tool results that already completed are discarded and no role: "tool" messages are pushed for the batch. The assistant message with tool_calls is already in this.messages, so the next model request violates the tool_call/tool_result pairing contract and the API call will fail. The serialized path pushed each result as it completed, so this is a regression introduced by the parallel path.

Fix: Catch per-tool errors inside each worker and store the error text as that tool's result, so every tool_call_id always gets a tool response and completed results survive a sibling failure.

Impact: Keeps the OpenAI message contract intact on aborts/hook failures and prevents losing already-completed parallel tool results.

Suggested change

	while (nextIndex < batch.length) {
	const index = nextIndex++
	results[index] = await this.handleToolCall(batch[index])
	}
	while (nextIndex < batch.length) {
	const index = nextIndex++
	try {
	results[index] = await this.handleToolCall(batch[index])
	} catch (error) {
	results[index] = `Tool execution failed: ${error instanceof Error ? error.message : String(error)}`
	}
	}