[BUG]: Agent Mode immediately ends with “Agent session complete” on macOS Desktop; invocations remain open and AgentHandler never starts

[Ray-vanSamsa]

How are you running AnythingLLM?

AnythingLLM desktop app on macOS / Apple Silicon.

What happened?

Agent Mode has stopped working completely. Normal Chat Mode still works correctly with the same LLM providers and models. In Agent Mode, every prompt ends almost immediately with:

Agent session complete.

No actual agent response is produced and no tool execution takes place.

I reproduced this with both a local OpenAI-compatible server via Generic OpenAI and OpenRouter, so a provider- or model-specific failure appears unlikely.

I first noticed the problem immediately after updating AnythingLLM Desktop from v1.16.0 to v1.16.1. However, I cannot conclude that v1.16.1 itself is the sole cause:

• downgrading to v1.16.0 did not restore Agent Mode;
• v1.16.0 had previously worked on this same Mac for a substantial period;
• v1.15.0 also failed when tested with the existing profile;
• resetting Electron/Chromium UI state did not help;
• v1.16.0 still failed after the complete AnythingLLM profile directory was moved aside and a new profile was created and configured from scratch.

The issue also reproduces with all Agent Skills disabled, zero MCP servers, and a new empty workspace.

Expected behavior

The Agent session should start, invoke the configured LLM, and return an agent response and/or execute tools as appropriate.

Actual behavior

The session terminates immediately with Agent session complete. The observable Agent execution does not start normally.

Backend logging

For a failed Agent Mode prompt, the backend logs the ordinary chat event:

[Event Logged] - sent_chat

However, there are no corresponding:

[AgentHandler] Start ...
[AgentLLM ...]

messages and no useful Agent-related exception in the backend or Electron logging.

The configured LLM itself is reachable. Normal local Chat Mode requests log, for example:

[GenericOpenAiLLM] Inference API: http://localhost:8000/v1
Model: mtplx-qwen38-27b-optimized-speed

With MCP disabled, the backend confirms:

[MCPHypervisor] Successfully started 0 MCP servers: []

Database evidence

After several failed Agent prompts, the newest rows in workspace_agent_invocations were created but remained closed = 0:

71|0|1788375202281
70|0|1788374560459
69|0|1788374294214
68|0|1788372594589
66|0|1788372219378

Query:

SELECT id, closed, createdAt
FROM workspace_agent_invocations
ORDER BY id DESC
LIMIT 5;

This shows that the invocation record is created, but it does not reach the normal database close path.

The public frontend displays Agent session complete. when the Agent WebSocket closes. The public server route initializes AgentHandler after a connection reaches the Agent WebSocket endpoint. Taken together with the missing AgentHandler start log and open invocation rows, the Agent WebSocket/session-start path is a plausible area to inspect. This does not establish a WebSocket handshake as the root cause: the observations do not distinguish a connection failure from a failure early in initialization.

Electron logging

I also started the Desktop application with Chromium/Electron logging enabled:

/Applications/AnythingLLM.app/Contents/MacOS/AnythingLLM --enable-logging

Renderer and backend startup logging worked. Around a failed Agent prompt, I saw the ordinary sent_chat event, but no subsequent AgentHandler/AgentLLM startup and no useful Agent- or WebSocket-related error.

Fresh-profile test

To exclude corruption or stale configuration, I moved the complete directory below out of the way:

~/Library/Application Support/anythingllm-desktop

I then launched v1.16.0, allowed it to create a new profile, and configured the application from scratch. Agent Mode failed identically.

This excludes the prior profile's SQLite database, workspaces, chats, workspace configuration, Local Storage, Session Storage, IndexedDB, and Electron/Chromium caches as necessary causes.

Version chronology

1. v1.16.0 was installed and Agent Mode had worked on this Mac.
2. I updated to v1.16.1.
3. I then noticed that Agent Mode no longer worked.
4. Downgrading to v1.16.0 did not restore it.
5. Resetting Electron/Chromium state did not restore it.
6. v1.16.0 with a completely fresh application profile still failed.
7. v1.15.0 was tested with the existing profile and also failed.

Therefore, the timing around the v1.16.1 update is notable, but I am deliberately not asserting a simple v1.16.1 regression.

I am aware that v1.16.1 includes #6191, which guards an Agent WebSocket send while the socket is still connecting. I cannot determine whether that history is related; this report persists on v1.16.1 and does not claim that specific mechanism as its cause.

Related but distinct reports

• [BUG]: Agent invocation not working #5065 is the closest prior silent-start symptom: normal chat worked, the Agent session ended immediately, logs stopped at sent_chat, and no request reached the LLM. That report was on Ubuntu ARM64, and its reporter ultimately found another service occupying port 3001. My reproduction is macOS Desktop, persists with a completely fresh profile, and has no established port-conflict diagnosis.
• [BUG]: Backend helper process crashes during agent sessions; ~830 MB leaked per agent exchange #6145 also involved macOS Apple Silicon and workspace_agent_invocations rows left at closed = 0, but its backend reached [AgentHandler], injected parsed files, then crashed after substantial memory growth. It was fixed by Fix agent backend crash from oversized tool reranker query #6152 and shipped in v1.16.1. My reproduction uses a new empty workspace with all Agent Skills disabled and never logs [AgentHandler] Start ..., so that crash signature is absent.
• [BUG]: @agent invocation immediately exits with “Agent session complete” #3666 showed the same frontend completion text in Docker and was attributed to missing WebSocket upgrade handling in a reverse proxy. This Desktop case has no reverse proxy and I am not assuming the same cause.
• The currently open [BUG]: @agent trigger / Agent workspace mode fails with 400 invalid_type JSON error – regression since v1.16.1 #6273 reports an explicit HTTP 400 invalid_type tool-schema error in Agent Mode. No such error or Agent startup log appears here, so its failure signature is materially different.

I can provide additional sanitized logs or run a targeted diagnostic if maintainers identify a specific Agent/session-start code path to inspect.

Are there known steps to reproduce?

1. Start AnythingLLM Desktop on macOS / Apple Silicon.
2. Configure a working LLM.
3. Open or create a workspace.
4. Verify that normal Chat Mode works.
5. Enable Agent Mode.
6. Send a simple prompt such as Ping. or Hello.
7. The UI almost immediately shows Agent session complete. without an agent response or tool call.

Additional reproductions:

• all Agent Skills disabled: fails;
• zero MCP servers: fails;
• new empty workspace: fails;
• completely fresh application profile under v1.16.0: fails.

LLM Provider & Model (if applicable)

Reproduced with:

• Generic OpenAI-compatible local endpoint: http://localhost:8000/v1
  • mtplx-qwen38-27b-optimized-speed
  • mtplx-qwen36-35b-a3b-optimized-balance
• OpenRouter
  • deepseek/deepseek-v4-flash-0731

Normal Chat Mode works with both provider paths; Agent Mode fails in the same way.

Embedder Provider & Model (if applicable)

Not relevant to this reproduction.

[shatfield4]

Does this only happen with the models you repro'd this bug with or have you tested it with other providers as well?