Local OpenAI-compatible agent fails with community access error

[Aladincz]

Summary

I am trying to use Buzz agents with a local OpenAI-compatible llama.cpp server. The local API works correctly when tested directly, but Buzz fails before sending the request to the LLM with:

Community access denied this agent — check its community membership.

This happens even though the agent is visible in the community and can send the initial welcome message.

Environment

• Buzz version: 0.5.3
• OS: macOS 15.7.5 intel
• Agent(s) tested: Bumble and Fizz
• Local model: qwen40.gguf
• Backend: llama.cpp
• Local API: http://127.0.0.1:8082/v1

Local model configuration

The Buzz UI does not provide a field for a custom OpenAI-compatible base URL. The provider settings only expose the provider/model configuration, so I configured the local endpoint through environment variables in Terminal.

I first quit Buzz and then ran:

export BUZZ_AGENT_PROVIDER=openai
export OPENAI_COMPAT_BASE_URL=http://127.0.0.1:8082/v1
export OPENAI_COMPAT_MODEL=qwen40.gguf
export OPENAI_COMPAT_API_KEY=ollama
export OPENAI_COMPAT_API=chat

The variables were verified with:

env | grep -E 'BUZZ_AGENT|OPENAI_COMPAT'

Buzz Desktop was then started from the same environment:

/Applications/Buzz.app/Contents/MacOS/buzz-desktop

The relevant Buzz settings were:

Provider: OpenAI-compatible
Model: qwen40.gguf
Thinking / Effort: none

Provider initially tested: OpenAI-compatible
BUZZ_AGENT_PROVIDER initially used: openai
BUZZ_AGENT_PROVIDER later tested: openai-compat

<img width="1101" height="633" alt="Image" src="https://github.com/user-attachments/assets/158a4964-5067-4f38-b543-a9459f126df4" />
<img width="360" height="246" alt="Image" src="https://github.com/user-attachments/assets/2c13a0ee-74c8-4344-9d89-74160fa17153" />

The local server was configured with a 16k context window because the default 4096 context was too small for Buzz agent prompts.

Verification that the local API works

The local endpoint responds correctly to the OpenAI-compatible chat endpoint:

curl http://127.0.0.1:8082/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen40.gguf",
    "messages": [
      {
        "role": "user",
        "content": "Odpověz pouze: funguje"     (Answer only: It works)
      }
    ],
    "temperature": 0
  }'

The response was a valid OpenAI-compatible chat.completion response and contained:

funguje (it works)

Previous version / earlier problems

Before upgrading from Buzz 0.5.2 to 0.5.3, the local model was reached successfully by Buzz. However, there were several problems:

1. With llama.cpp's default context size of 4096, Buzz generated requests larger than the available context:

   request (7566 tokens) exceeds the available context size (4096 tokens)
   

   and later requests were between approximately 8k and 14k tokens.

2. After increasing llama.cpp's context to 16384, Buzz successfully sent requests and llama.cpp generated responses. The logs showed prompt processing and decoded tokens, for example:

   n_decoded = 100
   tg = 2.6 t/s
   

3. Despite the model generating output, the response was sometimes not displayed in the channel or thread. It appeared that the agent was thinking or responding in the activity log, but no visible reply was published. (issue [Bug] Agents not replying #2421 )

4. The repository changelog for 0.5.3 contains:

   feat(agent): optional reply guard reminds a silent turn to publish (#3763)
   

   which appears potentially related to the previous silent-reply behavior.

After upgrading to 0.5.3, I can no longer reliably reach the LLM because the request now fails earlier with the community-access error described below.

Current reproducible behavior

1. Create or open an agent in Buzz.

2. The agent is visible in the community.

3. The agent can send its initial welcome message.

4. Reply to the agent in a direct message or thread.

5. The UI briefly shows Thinking.

6. The turn fails with:

   Community access denied this agent — check its community membership.
   

The same behavior occurs in two different communities. It is not limited to one community.

The error also occurs with both Bumble and Fizz.

No request is generated in the local llama.cpp log when this error occurs. This indicates that the failure happens before the agent calls the configured LLM endpoint.

Expected behavior

If the agent is visible in the community and can send a welcome message, replying to it should pass the community-access check and invoke the configured LLM provider.

Additional observations

• The error is not caused by the local model endpoint; the endpoint works independently via curl.
• The error occurs before any LLM request is sent.
• The agent appears to have community membership because it is visible and can send the welcome message.
• The same error occurs in multiple communities.
• Direct messages and thread interactions were both tested.
• The local OpenAI-compatible provider configuration was established through environment variables because the desktop UI does not expose a custom base URL field.

### Additional error observed later

After further testing, another error appeared in agent messages:

```text
⚠️ I couldn't process the last request after multiple retries
(Agent reported error (code -32001): llm auth:
{
  "error": {
    "message": "Incorrect API key provided: local. You can find your API key at https://platform.openai.com/account/api-keys.",
    "type": "invalid_request_error",
    "param": null,
    "code": "invalid_api_key"
  }
})

This indicates that, in this case, Buzz sent the dummy local API key (local) to the real OpenAI API instead of using the configured OpenAI-compatible endpoint.

The local provider was configured through:

Bash

export BUZZ_AGENT_PROVIDER=openai
export OPENAI_COMPAT_BASE_URL=http://127.0.0.1:8082/v1
export OPENAI_COMPAT_MODEL=qwen40.gguf
export OPENAI_COMPAT_API_KEY=ollama
export OPENAI_COMPAT_API=chat

The Buzz Desktop application was then launched from the same environment:

Bash

/Applications/Buzz.app/Contents/MacOS/buzz-desktop

After changing:

Bash

export BUZZ_AGENT_PROVIDER=openai

to:

Bash

export BUZZ_AGENT_PROVIDER=openai-compat

the OpenAI API-key error has not appeared again so far, although this is not yet conclusive because the error only appeared after multiple retries and with a delay.

The following error still occurs:

text

Community access denied this agent — check its community membership.

This suggests there may be two separate issues:

    In some situations, the openai provider ignores the OPENAI_COMPAT_* configuration and sends the dummy key to the real OpenAI API.
    Even with openai-compat, the agent may fail the community-access check before a request reaches the configured LLM endpoint.

No request appears in the local llama.cpp server log when the community-access error occurs.

[Aladincz]

[iroiro147]

Diagnosed the failure chain. Two distinct lanes here, and the second one is a Buzz-side copy bug worth a PR.

Lane A — CLI BUZZ_AGENT_PROVIDER=openai → api.openai.com 401. Code is behaving as documented in crates/buzz-agent/src/config.rs:804: when provider is openai and OPENAI_COMPAT_BASE_URL is unset, base URL defaults to https://api.openai.com/v1. The reporter's dummy key local was sent to the real OpenAI API and returned "Incorrect API key provided: local". This is actually correct code; it's the openai alias behaving like the well-known openai provider. Users who genuinely want a local llama.cpp server must set OPENAI_COMPAT_BASE_URL=http://127.0.0.1:<port>/v1. The alias openai-compat exists and maps to the same provider — acceptable UX, easy foot-gun, but not a defect.

Lane B — desktop spawned agent, local llama.cpp 401 surfaces as "Community access denied…". This is a Buzz copy bug:

1. Agent is configured as Local OpenAI-compatible (not relay-mesh). Spawn env passes user's OPENAI_COMPAT_* through unchanged; that's correct.
2. llama.cpp at :8082 rejects with 401 body {"message":"multi-user-authorization"}. This is a llama.cpp multi-user auth error (server launched with --api-key and the supplied key doesn't match).
3. buzz-agent's HTTP layer treats 401/403 as LlmAuth(read_error_body) (crates/buzz-agent/src/llm.rs:1832-1836).
4. Serialized as JSON-RPC -32001 → desktop supervisor recovers it into ManagedAgent.lastErrorCode.
5. desktop/src/features/agents/lib/friendlyAgentLastError.ts:80 rewrites every -32001 to RELAY_MESH_DENIED_COPY = "Community access denied this agent — check its community membership." — regardless of whether the agent is mesh.
6. The reporter sees "Community access denied" instead of the actionable "401 from your llama.cpp — the API key you configured doesn't match the server's".

The fix is provider-aware dispatch in friendlyAgentLastError: only rewrite -32001 to the mesh copy when agent.provider === "relay-mesh"; otherwise pass through the raw lastError (minus wrapping) so the reporter sees the real llama auth message.

I'll open a PR with that fix, a test that mirrors the reporter's lane (non-mesh provider + 401 → raw error text, not the mesh copy), and a regression test that mesh providers still map to the mesh denied copy.

[Aladincz]

Very glad it’s moving. Was not sure it’s issue of my setup.
I wish I could help to make Buzz really independent platform, free of Anthropic, OpenAI and others. If I can help to fine tune local Llm, openrouter, @diegosouzapw/OmniRoute access is working or other independent ways, I’ll be glad.