macOS screencapture 输出 PNG，但代码硬编码 mimeType 为 image/jpeg，
导致 API 报错 "specified using image/jpeg but appears to be image/png"。
改为通过 magic bytes 检测实际图片格式。
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix stop_reason always null in assembled AssistantMessage by applying
the value captured from message_delta event
- Reset partialMessage to null after message_stop to prevent duplicate
AssistantMessage emission causing doubled content in next API request
- Forward computed maxTokens into buildOpenAIRequestBody as max_tokens
so OpenAI-compatible endpoints receive the intended output cap
- Extract assembleFinalAssistantOutputs helper to deduplicate message
assembly logic between message_stop handler and post-loop fallback
- Fix test helper to use events parameter instead of hidden global
- Add regression test for max_tokens request forwarding
Signed-off-by: guunergooner <tongchao0923@gmail.com>
Replace StdoutMessageWithSession conditional type with simpler
TransportMessage intersection type. The conditional type was
over-engineered for what is just StdoutMessage & { session_id? }.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Eliminate unsafe `as any` casts across 21 non-test source files,
replacing them with specific type annotations:
- Bridge transport: use StdoutMessage type for write/writeBatch calls
- print.ts: type msg.request as Record<string, unknown> for unknown
SDK control subtypes; use StdoutMessage for output.enqueue()
- API providers (openai/grok/gemini): import ChatCompletion types,
type streams as AsyncIterable<ChatCompletionChunk>, type request
bodies as ChatCompletionCreateParamsStreaming
- Computer use executor: use Partial<ResolvePrepareCaptureResult>
for cross-platform screenshot result
- Components: replace Ink color string casts with proper typing
- Win32 bridge: type stdin as Writable after null check
All 2453 tests pass with 0 failures.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Apply proper TypeScript type corrections without any unsafe casts:
- Fix unknown/never/{} types from decompilation
- Correct function signatures and parameter types
- Add missing type declarations and interfaces
- Fix Ink component prop types
- Update API client/provider type annotations
Test files with mock data casts are included as-is (acceptable pattern).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* 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>
