Cursor Agent ACP live process returns sign-in prompt as assistant content after auth state goes stale

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

A long-lived Cursor Agent ACP process can start authenticated, complete a prompt successfully, then later return Please sign in to continue as normal assistant content on a subsequent session/prompt.

Fresh Cursor Agent invocations in the same broker environment still authenticate successfully, so this appears scoped to the stale live ACP process/session rather than the system-wide Cursor login or API key.

Steps to Reproduce

Run:
agent --model composer-2.5 acp
A Cursor ACP process was started and completed an initial prompt successfully.

Later, the same live ACP process/session was reused. Instead of returning a structured auth error or refreshing auth state, it emitted:

Please sign in to continue

This was surfaced as assistant text and the run completed successfully from the caller’s perspective.

Expected Behavior

When a long-lived ACP process loses or cannot use its auth state, Cursor Agent should either:
Refresh/re-read valid auth from its environment or credential store, or
Return a structured ACP/JSON-RPC authentication error, or
Terminate the ACP session/process with a clear auth failure.
It should not emit “Please sign in to continue” as normal assistant response content.

Operating System

Linux

Version Information

Cursor Agent CLI: 2026.06.19-20-24-33-653a7fb

For AI issues: which model did you use?

composer-2.5

Additional Information

The parent broker environment still had valid Cursor credentials:
CURSOR_API_KEY present in broker process environment
Running agent models with the broker process environment succeeded and listed models.
A fresh Cursor Composer run through the same broker also succeeded:
model_name=composer-2.5
prompt=“Return exactly OK.”
response=“OK”

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. The repro steps and debugging really helped.

This is a confirmed bug. In an ACP session, when the auth state for a long-running process expires, the backend correctly returns an auth error, but the ACP layer unwraps it into normal assistant text agent_message_chunk and ends the turn as end_turn success instead of returning a structured JSON-RPC/ACP error. We’re already tracking the issue, but I can’t share an ETA for a fix yet.

Workaround for now. A long-running ACP process doesn’t reload auth mid-session, so restarting the ACP process is enough. New invocations read auth on startup, which is why agent models and fresh runs in the same broker environment keep working for you. Also make sure CURSOR_API_KEY is available to the process, or that you’ve run agent login before starting.

Once there’s an update on the fix, I’ll reply in the thread.