alfin06/swegent-issues-filtered huggingface dataset:
unknown format "path" in schema

### What happened?

I'm using MCP Docker and I activated Obsidian extension. When Gemini calls the tool `obsidian_append_content`if shows the following error: 
```shell
 ╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
 │ x  obsidian_append_content (MCP_DOCKER MCP Server) {"filepath":"Wizipet API Clients/Python Client.md","content":"# Project Wizipet AI Chatbot\n\n## Introduction\n\nWizipet application shoudl shift to offer AI based…  │
 │                                                                                                                                                                                                                          │
 │    unknown format "path" ignored in schema at path "#/properties/filepath"                                                                                                                                               │
 ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
```


### What did you expect to happen?

## Expected behaviour

Accept the format and execute the tool.

## Additional consideration

When the mcp tool is directly executed from the command line:

```shell
$ docker mcp tools call obsidian_append_content filepath="API Clients/Python Client.md" content="Try this"
Tool call took: 836.221417ms
Successfully appended content to API Clients/Python Client.md
```

<img width="763" height="492" alt="Image" src="https://github.com/user-attachments/assets/1e97ea51-f08b-4b08-a6ee-3ba15d328a57" />

### Client information


* **CLI Version:** 0.4.1
* **Git Commit:** 70ff7a36
* **Session ID:** adaff1ac-08ca-41c5-bf07-754c448e9691
* **Operating System:** darwin v22.11.0
* **Sandbox Environment:** no sandbox
* **Model Version:** gemini-2.5-pro
* **Memory Usage:** 175.0 MB


### Login information

## The format of the property
The format option is conform with what is mentioned in the tool's properties' schema:

- The command
```shell
docker mcp tools inspect obsidian_append_content --format json
```

- The output
```json
{
  "annotations": {},
  "description": "Append content to a new or existing file in the vault.",
  "inputSchema": {
    "properties": {
      "content": {
        "description": "Content to append to the file",
        "type": "string"
      },
      "filepath": {
        "description": "Path to the file (relative to vault root)",
        "format": "path",
        "type": "string"
      }
    },
    "required": [
      "filepath",
      "content"
    ],
    "type": "object"
  },
  "name": "obsidian_append_content"
}
```


### Anything else we need to know?

_No response_

Labels: priority/p2, area/agent
State: closed
[Request] 新增qwen3 coder模型

### 🥰 需求描述

阿里云百炼新上架了商业版`qwen3-coder-plus`和开源版`qwen3-coder-480b-a35b-instruct`，需要新增

### 🧐 解决方案

新增`qwen3-coder-plus`和`qwen3-coder-480b-a35b-instruct`

### 📝 补充信息

_No response_

Labels: released
State: closed
Support for OPENAI_BASE_URL

### Description

We are using sentry mcp (https://github.com/getsentry/sentry-mcp) that is using openai library.
For security reasons we must use openai api via proxy.

You can configure OPENAI_API_KEY using env variable.
However we would like to also specify base url via OPENAI_BASE_URL.

Would it be possible to implement also specifying base url via env variable for other tools that are using ai-sdk to work out of the box.

Alternative is to configure it in the code, but other tools using it are not making it configurable:
```
const openai = createOpenAI({
    // apiKey: "OPENAI_API_KEY", // from ENV
    baseURL:"https://llm-proxy.mycompany.com/openai/v1",
});
```


### AI SDK Version

    "@ai-sdk/openai": "^2.0.28",
    "ai": "^5.0.39"

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: ai/provider, support, provider/openai, provider/openai-compatible
State: closed
Cant Add cerebras as a provider

### 📦 Platform

Official Preview

### 📦 Deploymenet mode

client db (lobe-chat image)

### 📌 Version

I want to add Cerabras as provider 

### 💻 Operating System

Windows

### 🌐 Browser

Edge

### 🐛 Bug Description

https://cloud.cerebras.ai/?utm_source=homepage

not working 

### 📷 Recurrence Steps

_No response_

### 🚦 Expected Behavior

_No response_

### 📝 Additional Information

_No response_

Labels: released, unconfirm
State: closed
Codex CLI returns `agent_message` but VK expects `assistant_message` → no assistant messages, `external_session_id` stays `None

Hello,

In my environment (Windows 11 + WSL2 Ubuntu, Vibe Kanban v0.0.95, Codex CLI 0.41.0), Codex attempts consistently fail because Vibe Kanban never receives an initial assistant message.

### Steps to reproduce

1. Install Codex CLI v0.41.0 (`npm i -g @openai/codex`).

2. Start Vibe Kanban latest:

   ```bash
   RUST_LOG=debug npx --yes --cache /tmp/empty-cache vibe-kanban@latest
   ```

3. Create a new task card with executor = CODEX, and press **Create & Start**.

4. Observe server logs.

### Observed behavior

- Worktree is created successfully.

- Executor session is created, but:

  ```
  Creating executor session: ... external_session_id=None (will be set later)
  ...
  No assistant message found for execution <id>
  ```

- UI shows no assistant response.

- Using Claude Code instead works fine.

### Additional investigation

Running Codex CLI directly in the worktree shows that the stream emits `agent_message` instead of `assistant_message`:

```json
{"id":"0","msg":{"type":"agent_message","message":"ok"}}
```

Vibe Kanban seems to only recognize `assistant_message` events, so it treats this as “no assistant message” and leaves `external_session_id=None`.

### Expected behavior

- Vibe Kanban should treat `agent_message` (and possibly related new message types like `agent_reasoning`) as valid assistant output, so that `external_session_id` is set and the first assistant response appears in the UI.

### Environment

- OS: Windows 11 + WSL2 Ubuntu 22.04
- Vibe Kanban: v0.0.96
- Codex CLI: 0.41.0
- Node/npm: (fill in your versions)
- Project location: both `/home/...` and `/mnt/c/...` tested, same result

### Workarounds tried

- Downgrading Codex CLI not possible (no matching versions published on npm except 0.34/0.35/0.36/0.41).
- Claude Code agent works fine as a temporary solution.
- A wrapper script that rewrites `agent_message` → `assistant_message` in the Codex JSON stream makes Codex usable again.

### Related issues

- \#428 (Unknown message types after GPT-5 switch)
- \#809 (pre-execution errors not surfaced in UI)
- \#769 (Codex CLI 0.36.0 `--ask-for-approval` flag incompatibility)



State: closed
Possible bug with incorrect types in `generateText` result - `providerOptions` vs `providerMetadata`

### Description

The interface `GenerateTextResult` claims that the `reasoning` is `Array<ReasoningPart>`.
In turn, `ReasoningPart` is defined as:

```
/**
 * Reasoning content part of a prompt. It contains a reasoning.
 */
export interface ReasoningPart {
  type: 'reasoning';

  /**
The reasoning text.
   */
  text: string;

  /**
Additional provider-specific metadata. They are passed through
to the provider from the AI SDK and enable provider-specific
functionality that can be fully encapsulated in the provider.
 */
  providerOptions?: ProviderOptions;
}
```

However, I've observed cases where the output actually contains `providerMetadata` instead of `providerOptions`. 

I am able to consistently reproduce this with 1) Claude 4 Sonnet, 2) extended thinking on and 3) tools enabled.

### AI SDK Version

"@ai-sdk/amazon-bedrock": "^3.0.16",
"@ai-sdk/anthropic": "^2.0.12",
"@ai-sdk/azure": "^2.0.24",
"@ai-sdk/google": "^2.0.12",
"@ai-sdk/google-vertex": "^3.0.20",
"@ai-sdk/openai": "^2.0.24",
"ai": "^5.0.33",

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: bug, ai/core
State: closed
阿里云百炼的coder和kimi2参数配置有误

### 📦 部署环境

Docker

### 📦 部署模式

服务端模式(lobe-chat-database 镜像)

### 📌 软件版本

v1.106.3

### 💻 系统环境

Windows

### 🌐 浏览器

Chrome

### 🐛 问题描述

阿里云百炼的`qwen3-coder-480b-a35b-instruct`模型支持工具调用，目前没有正确配置

阿里云百炼的`Moonshot-Kimi-K2-Instruct`模型实测不支持工具调用，需要取消fc参数配置

<img width="671" height="314" alt="Image" src="https://github.com/user-attachments/assets/dc8ce508-e076-476f-98fd-053a4634391b" />


### 📷 复现步骤

_No response_

### 🚦 期望结果

_No response_

### 📝 补充信息

_No response_

Labels: released, Model Provider, unconfirm
State: closed
阿里云百炼的qwen3-235b-a22b-thinking-2507模型缺少参数enable_thinking为True而无法调用

### 📦 部署环境

Docker

### 📦 部署模式

服务端模式(lobe-chat-database 镜像)

### 📌 软件版本

v1.106.3

### 💻 系统环境

Windows

### 🌐 浏览器

Chrome

### 🐛 问题描述

阿里云百炼的`qwen3-235b-a22b-thinking-2507`模型缺少参数`enable_thinking`为`True`而无法调用


### 📷 复现步骤

交互时弹出如下错误`The value of the enable_thinking parameter is restricted to True`：
```
{
  "error": {
    "code": "invalid_parameter_error",
    "type": "invalid_request_error",
    "message": "Provider API error: <400> InternalError.Algo.InvalidParameter: The value of the enable_thinking parameter is restricted to True. (request id: 20250730xxxxxxxxxxxxxxxx)"
  },
  "endpoint": "***/v1",
  "provider": "qwen"
}
```

### 🚦 期望结果

可以正常调用

### 📝 补充信息

_No response_

Labels: released, Model Provider, unconfirm
State: closed
Mistral provider does not have an option to disable parallel tool calls

### Description

We're trying to forcefully disable parallel tool calls with Mistral provider, but we didn't see this option anywhere in this SDK. Any ideas on how to go about that?

We didn't see any options for this either with the Mistral provider nor with the AI core streamText() API.

Using the following doesn't seem to work:
```
      providerOptions: {
        mistral: {
          parallelToolCalls: false,
        },
      },
```

Thanks!

### AI SDK Version

"@ai-sdk/mistral": "2.0.14",
"@ai-sdk/openai": "2.030",
"ai": "5.0.44"

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: ai/provider, support, provider/mistral
State: closed
Ollama integration fails when mirostat is set to "Disabled" in LangFlow

![Image](https://github.com/user-attachments/assets/dfc15f1d-04b9-4eab-b44f-ad9825639325)

### Summary
When using a model in LangFlow with Ollama and `mirostat` set to "Disabled", the integration breaks due to invalid parameters being sent to the Ollama API. The error resolves only after removing `"mirostat": 0` and its related parameters (`mirostat_eta`, `mirostat_tau`) from the model configuration.
---

### Steps to Reproduce

1. Use LangFlow with an Ollama-compatible model like `qwen2.5:0.5b`
2. Set `mirostat` to "Disabled" (default value)
3. Run a prompt or connect to an Agent
4. Error: the Ollama API responds with an invalid option error

**Console Output:**


Labels: bug, jira
State: closed
`providerOptions` are not correctly passed for Azure embeddings 🐛

### Description

The `@ai-sdk/azure` package's `embed` function does not seem to correctly process `providerOptions` when creating embeddings. 
The provided documentation example suggests using `providerOptions: { azure: { ... } }` to pass specific parameters like dimensions and user for an Azure model.

```ts
import { azure } from '@ai-sdk/azure';
import { embed } from 'ai';

const { embedding } = await embed({
  model: azure.textEmbedding('your-embedding-deployment'),
  value: 'sunny day at the beach',
  providerOptions: {
    azure: { // <-- This seems to be the issue
      dimensions: 512,
      user: 'test-user',
    },
  },
});
```
However, this configuration fails to apply the options to the underlying request. In contrast, if I use the `@ai-sdk/openai` package with `providerOptions: { openai: { ... } }`, the options are correctly passed and the request is successful.

Upon reviewing the `@ai-sdk source` code, it appears that the internal logic for handling providerOptions might be specifically looking for an openai key, even when the model provider is Azure. This suggests that the documentation is either misleading or the implementation is bugged, as the azure key in `providerOptions` is seemingly ignored.

### Reproduction Steps

- Set up a project with `@ai-sdk/azure` and ai packages.
- Configure your environment variables for Azure AI services.
- Use the embed function with azure.textEmbedding as shown in the documentation example.
- Add dimensions or user to the providerOptions object under the azure key.

Observe that the request to Azure does not include these parameters, or the call fails due to invalid parameters.


### AI SDK Version

- ai: 5.0.42
- @ai-sdk/provider: 2.0.0
- @ai-sdk/provider-utils: 3.0.8
- @ai-sdk/azure: 2.0.29

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: documentation, pull request welcome, ai/provider, provider/openai, provider/azure
State: closed
pass provider version as part of headers (needs to be implemented in each provider. Begin with gateway)

User-agent string only contains the `ai` version along with runtime environment. This change will append provider versions to the header!

Packages Checklist

- [x] `gateway`
- [x] `openai`
- [x] `anthropic`
- [x] `google`
- [x] `google-vertex`
- [x] `azure`
- [x] `amazon-bedrock`
- [x] `cohere`
- [x] `mistral`
- [x] `groq`
- [x] `cerebras`
- [x] `deepinfra`
- [x] `deepseek`
- [x] `fireworks`
- [x] `perplexity`
- [x] `replicate`
- [x] `togetherai`
- [x] `xai`
- [x] `vercel`
- [x] `openai-compatible`
- [x] `elevenlabs`
- [x] `assemblyai`
- [x] `deepgram`
- [x] `gladia`
- [x] `revai`
- [x] `luma`
- [x] `fal`
- [x] `hume`
- [x] `lmnt`
- [x] `langchain`
- [x] `llamaindex`
- [x] `valibot`


Labels: feature, ai/provider
State: closed
feature: allow tool.execute to delegate to client side execution

### Description

Right now, if a tool has an `execute` function, it will always be called server-side during `streamText`.

```ts
  // Only execute tools that are not provider-executed:
            if (tool.execute != null && toolCall.providerExecuted !== true) {
              const toolExecutionId = generateId(); // use our own id to guarantee uniqueness
              outstandingToolResults.add(toolExecutionId);

             // more code here tall calls tool.execute()

          }
```

It would be very useful for complex use cases if there were a way to dynamically decide if a tool call should be executed client side.

Looking at the current code in `run-tool-transformations.ts`, the easiest addition would be some sort of `canExecuteServer` function, that receives the input, and return a result object, or `boolean`.

It could be something like this:

```ts
// Only execute tools that are not provider-executed:
            if (
              tool.execute != null 
              && toolCall.providerExecuted !== true 
              && tool.shouldExecuteServer(toolCall.input) // THIS IS NEW.
            ) {
              const toolExecutionId = generateId(); // use our own id to guarantee uniqueness
              outstandingToolResults.add(toolExecutionId);


           }
```

This would make use cases like human in loop, and complex back and forth between client/server so much easier.

Right now, human in the loop workflows require these complex workarounds with custom data-streaming of results.



### AI SDK Version

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: feature, ai/core
State: closed
Missing `cachedInputTokens` for kimi-k2 on groq

### Description

Was using the new Posthog llm analytics and found out cached tokens are not tracked for kimi k2 on groq. The actual response has the correct usage but ai sdk is not passing that.
https://console.groq.com/docs/prompt-caching#tracking-cache-usage

Probably missing here, will open a PR.

https://github.com/vercel/ai/blob/5c5fab361b8a8392c4d9b6083be67019fff9ec09/packages/groq/src/groq-chat-language-model.ts#L223-L227

### AI SDK Version

 "@ai-sdk/groq": "^2.0.4",
 "ai": "^5.0.28",


### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: feature, ai/provider, provider/groq
State: closed
希望利用Gemini API赋予Gemini模型网页阅读功能

### 🥰 需求描述

希望为Genimi模型添加网页阅读功能。目前，如果在LobeChat内要求Gemini模型（以Gemini 2.5 Pro为例）总结某网页的话，模型总是会给出幻觉回复，推测目前还不具备该功能。

### 🧐 解决方案

目前，Gemini API已经推出实验版的URL Context功能，希望能将其整合进LobeChat。

### 📝 补充信息

_No response_

Labels: released, provider:gemini
State: closed
reworkd_platform.web.api.errors.OpenAIError: -351 is less than the minimum of 1 - 'max_tokens'

### Please check that this issue hasn't been reported before.

- [X] I searched previous [Bug Reports](https://github.com/reworkd/AgentGPT/labels/bug) didn't find any similar reports.

### Expected Behavior

I encoutered this issue when running the docker. 
Thanks,
Daniel
<img width="953" alt="image" src="https://github.com/reworkd/AgentGPT/assets/22897462/6e9df5b7-d9cc-48af-a36f-bf237d7e0bc9">


### Current behaviour

doesn't seem to produce any results

### Steps to reproduce

run the containter and put in a task

### Possible solution

I don't know

### Which Operating Systems are you using?

- [ ] Android
- [ ] iPhone/iPad
- [ ] Linux
- [X] macOS
- [ ] Windows

### Acknowledgements

- [X] My issue title is concise, descriptive, and in title casing.
- [X] I have searched the existing issues to make sure this bug has not been reported yet.
- [X] I am using the latest version of AgentGPT.
- [X] I have provided enough information for the maintainers to reproduce and diagnose the issue.

Labels: bug
State: closed
调用第三方GPT-5时失败

### 📦 部署环境

Vercel

### 📦 部署模式

服务端模式(lobe-chat-database 镜像)

### 📌 软件版本

v1.111.11

### 💻 系统环境

iOS

### 🌐 浏览器

Chrome

### 🐛 问题描述

错误提示如下：
{
  "code": "invalid_text_request",
  "type": "openai_error",
  "error": {
    "code": "invalid_text_request",
    "type": "openai_error",
    "param": "",
    "message": "json: cannot unmarshal string into Go struct field url of type bool  (request id: 20250813201339277006589EtSGahGi)"
  },
  "param": "",
  "status": 400,
  "headers": {
    "date": "Wed, 13 Aug 2025 12:13:40 GMT",
    "connection": "keep-alive",
    "content-type": "text/event-stream",
    "cache-control": "no-cache",
    "transfer-encoding": "chunked",
    "x-rixapi-request-id": "20250813201339277006589EtSGahGi"
  },
  "provider": "openai"
}

### 📷 复现步骤

_No response_

### 🚦 期望结果

_No response_

### 📝 补充信息

该供应商的其他模型均可正常响应，但此特定模型出现异常。经与供应商沟通确认，对方分析认为：该模型使用的是逆向的chat接口，而 LobeHub 统一调用官方最新的 response 接口，两者接口规范不兼容，导致请求失败

Labels: released, unconfirm
State: closed
After creating a view, the answer generated does not indicate that it originates from a view

**Describe the bug**
In version 0.10.0, after creating a view, the answer generated does not indicate that it originates from a view.

**To Reproduce**
Steps to reproduce the behavior:
1. Go to home
2. Create a view
3. Ask a questions same with the question we saved as a view
4. Observe that the answer does not indicate it comes from the view.

**Expected behavior**
The response should clearly indicate if it originates from a view to provide transparency about the data source.

**Desktop (please complete the following information):**
- OS: macOS
- Browser: Chrome

**Wren AI Information**
- Version: 0.10.0
- LLM_PROVIDER= openai
- GENERATION_MODEL= gpt-4o-mini



Labels: bug
State: closed
Support textVerbosity option for openai-compatible

### Description

I've configured [opencode.ai](https://opencode.ai) to use @ai-sdk/openai-compatible to talk to our Azure gateway serving the OpenAI models. When the model name contains the string `gpt-5` opencode adds the [`textVerbosity` option](https://ai-sdk.dev/providers/ai-sdk-providers/openai#verbosity-control) and this cause failure as the provider returns `AI_APICallError: Unknown parameter: 'textVerbosity'.`.

It seems like this option is just passed as is to the underlying wire protocol.  If I read the [OpenAI chat completions protocol description](https://platform.openai.com/docs/api-reference/chat/create#chat-create-verbosity) correctly it should be turned into `verbosity` on the wire.

### AI SDK Version

@ai-sdk/openai-compatible 1.0.18

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: feature, ai/provider, provider/azure, provider/openai-compatible
State: closed
Bug: AI SDK Incompatible with vLLM OpenAI Endpoint

### Description

# Bug: AI SDK Fails with vLLM OpenAI Endpoint

## Description
When using the latest `vLLM` serve with OpenAI-compatible endpoint, the Vercel AI SDK throws an error during inference.

```
Error message: [{"expected":"object","code":"invalid_type","path":["incomplete_details"],"message":"Invalid input: expected object, received undefined"}]
```

## Reproduction Steps
```ts
import { createOpenAI } from '@ai-sdk/openai';
import { generateObject } from 'ai';
import { z } from 'zod';

const openai = createOpenAI({
    apiKey: 'sk-dummy',
    baseURL: 'http://localhost:8000/v1',
});


const { object } = await generateObject({
    model: openai('meta-llama/Llama-3.1-8B-Instruct'),
    schema: z.object({
        name: z.string(),
    }),
    prompt: 'Generate a name.',
});
console.log(JSON.stringify(object, null, 2));
```

### Similar Issues

https://github.com/vllm-project/vllm/issues/11415

### AI SDK Version

- ai: ^5.0.48

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Labels: bug, ai/provider, support, provider/openai, provider/openai-compatible
State: closed
自定义服务商没办法加载打开配置

### 📦 Platform

Other

### 📦 Deploymenet mode

client db (lobe-chat image)

### 📌 Version

v1.113.1

### 💻 Operating System

Windows

### 🌐 Browser

Edge

### 🐛 Bug Description

自定义服务商没办法加载打开配置，其他已有的都是好的

### 📷 Recurrence Steps

![Image](https://github.com/user-attachments/assets/3bcaf0e7-e513-451f-a31f-446bc896b4b7)

### 🚦 Expected Behavior

_No response_

### 📝 Additional Information

_No response_

Labels: released, unconfirm
State: closed