* fix: reorder tool and user messages for OpenAI API compatibility (#168)
Fixes#168
OpenAI requires that an assistant message with tool_calls be immediately
followed by tool messages. Previously, convertInternalUserMessage
output user content before tool results, causing 400 errors.
Now tool messages are pushed first.
* fix: 修复OpenAI兼容层中deferred tools处理问题
提交描述:
修复了在使用OpenAI兼容API时TaskCreate工具调用失败的问题。
问题:
- 当使用OpenAI兼容API模型时，调用TaskCreate工具出现"InputValidationError: The required
parameter `subject` is missing"错误
- OpenAI兼容层没有正确处理deferred tools的过滤逻辑，导致工具schema没有被正确发送给模型
修复:
1. 在OpenAI兼容层中添加了与Anthropic API路径一致的deferred tools处理逻辑
2. 导入必要的工具搜索相关函数: isToolSearchEnabled, extractDiscoveredToolNames,
isDeferredTool等
3. 实现工具过滤逻辑:
- 检查工具搜索是否启用
- 构建deferred tools集合
- 过滤工具列表: 只包含非deferred工具或已发现的deferred工具
- 为deferred tools设置deferLoading标志
4. 修正了extractDiscoveredToolNames函数的导入路径错误
影响:
- 解决了TaskCreate工具调用时的参数验证错误
- 确保OpenAI兼容层与Anthropic API路径在处理deferred tools时行为一致
- 支持工具搜索功能在OpenAI兼容模式下正常工作
修改的文件:
- src/services/api/openai/index.ts - 主要修复文件
测试建议:
1. 使用OpenAI兼容API模型时，TaskCreate工具应该可以正常调用
2. 如果工具搜索功能启用，可能需要先使用ToolSearchTool来发现TaskCreate工具
3. 验证工具调用时不再出现"InputValidationError"错误
这个修复确保了当使用OpenAI兼容API（如Ollama、DeepSeek、vLLM等）时，deferred
tools（如TaskCreate）能够被正确处理，解决了工具调用失败的问题。
* fix: 更新未发送工具架构提示，提供OpenAI兼容模型的使用步骤
* fix: Handle undefined command names in getCommandName function
- Modified getCommandName in src/types/command.ts to return empty string instead of undefined when cmd.name is undefined
- Added null checks in src/hooks/useTypeahead.tsx to safely handle command names
- Prevents "undefined is not an object" error when FEATURE_BUDDY=1 and FEATURE_FORK_SUBAGENT=1 are enabled
The error occurred because getCommandName(cmd) could return undefined when cmd.name was undefined, causing .length access to fail.
* feat: 支持自托管的 remote-control-server (#214)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
* feat: Add DeepSeek thinking mode support for OpenAI compatibility layer
- Add DeepSeek reasoning models support (deepseek-reasoner and DeepSeek-V3.2)
- Automatic thinking mode detection based on model name
- Inject thinking parameters in request body (both official API and vLLM formats)
- Preserve reasoning_content in message conversion for tool call iterations
- Extract buildOpenAIRequestBody() for testability
- Treat multimodal inputs (e.g. images) as new turn boundaries
- Fix env var cleanup in tests to prevent state leak
Signed-off-by: guunergooner <tongchao0923@gmail.com>
* docs: update contributors
---------
Signed-off-by: guunergooner <tongchao0923@gmail.com>
Co-authored-by: guunergooner <18660867+guunergooner@users.noreply.github.com>
Fixes#168
OpenAI requires that an assistant message with tool_calls be immediately
followed by tool messages. Previously, convertInternalUserMessage
output user content before tool results, causing 400 errors.
Now tool messages are pushed first.
Reverse-engineer the missing daemon + remoteControlServer implementation
by tracing the call chain from existing code:
- src/daemon/main.ts: restore from stub to full supervisor (spawn/monitor
workers, exponential backoff restart, graceful shutdown)
- src/daemon/workerRegistry.ts: restore from stub to worker dispatcher
(remoteControl kind → runBridgeHeadless())
- src/commands/remoteControlServer/: new slash command /remote-control-server
(alias /rcs) for managing the daemon from REPL
- build.ts + scripts/dev.ts: enable DAEMON feature flag
Both official CLI 2.1.92 and our codebase had the command registered in
commands.ts but the directory and daemon implementation were missing.
The bottom layer (runBridgeHeadless in bridgeMain.ts) was already complete.
Co-authored-by: unraid <local@unraid.local>
The earlyInput capture's escape sequence detection was too simplistic — it
only checked if the byte after ESC fell in 0x40-0x7E range, treating it as
a terminator. This caused DCS sequences (e.g. XTVERSION `\x1bP>|iTerm2
3.6.4\x1b\\`) and CSI parameter sequences (e.g. DA1 `\x1b[?64;...c`) to
partially leak into the input buffer as `>|iTerm2 3.6.4?64;1;2;4;6;17;18;21;22c`.
Fix by handling each escape sequence type per ECMA-48:
- CSI (`ESC [`): skip parameter + intermediate bytes, then final byte
- DCS/OSC/SOS/PM (`ESC P/]/X/^`): scan to BEL or ST terminator
- Other: keep single-byte skip
Closes#171
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Add xAI Grok as a new API provider. Reuses OpenAI-compatible message/tool
converters and stream adapter with Grok-specific client and model mapping.
Default model mapping:
opus → grok-4.20-reasoning
sonnet → grok-3-mini-fast
haiku → grok-3-mini-fast
Users can customize mapping via:
- GROK_MODEL env var (override all)
- GROK_MODEL_MAP env var (JSON family map, e.g. {"opus":"grok-4"})
- GROK_DEFAULT_{FAMILY}_MODEL env vars
Activation: CLAUDE_CODE_USE_GROK=1 or modelType: "grok" in settings.json
Also integrates with /provider command for runtime switching.
