fix(app): wait for signed-in Den startup before Run Task

[reachjalil]

Safety contract — read this first

This PR gates the composer by actual Den session state, not by whether the installation requires sign-in.

• Signed out (including tokenless startup): the input and Run Task remain available.
• Signed in: the prompt input is disabled and Run Task remains disabled until the app-level Den/OpenWork Cloud MCP startup lifecycle is ready.
• Restoring a saved Den session: treated as signed in while restoration is pending, so the user sees an in-composer loading state and the prompt cannot outrun skill/tool injection.
• Retained session with Den currently unavailable: fail closed with a reconnect message, Retry, and Open Connect.

requireSignin is deliberately not read or used by this change. It controls whether the app forces authentication; it does not decide whether a signed-in user's task needs the signed-in Den context.

Startup and submission sequencing

Connection establishment is not performed inside the submit callback:

1. useSessionMcpMaintenance starts and repairs the signed-in workspace's OpenWork Cloud MCP connection in the background.
2. While checking or retrying, the prompt editor is non-editable and displays Connecting signed-in services…; Run Task is disabled and displays its loading state.
3. If startup fails, the editor stays non-editable and displays Reconnect Den to continue; the existing failure surface provides Retry and Open Connect.
4. Enter, steer, queue, and auto-send paths use the same blocker instead of consuming or sending the prompt early.
5. The submit callback keeps only a synchronous defensive guard so keyboard, control, or stale UI paths cannot bypass the disabled composer. It does not wait for or repair Den.
6. Analytics run-start signals and the OpenCode prompt are emitted only after the app-level state is ready.

Any existing draft remains stored while the loading/reconnect state occupies the input area and returns unchanged when readiness becomes available.

For chat-first startup with no workspace, OpenWork must first create the local workspace that the engine connection is scoped to. The composer shows Preparing your workspace… during that setup. The seeded prompt then remains held by the session surface and cannot auto-send until the new workspace reaches ready. This avoids a connection-before-workspace deadlock without starting the agent turn early.

Behavior matrix

Auth / startup state	Composer behavior
Signed out	Input enabled; Run Task allowed
Auth check with no saved session token	Input enabled; Run Task allowed
Auth check with a saved session token	Input locked with loading state; Run Task disabled
Signed in + connection checking/retrying	Input locked with loading state; Run Task disabled
Signed in + connection ready	Input enabled; Run Task allowed
Signed in + connection failed or skipped	Input locked with reconnect state; Run Task disabled; Retry/Open Connect shown
Retained session but Den unavailable	Input locked with reconnect state; Run Task disabled; Retry/Open Connect shown

Risk and caution

This is intentionally fail-closed for the signed-in cohort. The strict readiness lifecycle verifies the openwork-cloud MCP connection, direct tools, plugin canaries, and provider/model tool projection. A systemic projection or compatibility regression can therefore disable the composer for every signed-in user, even when ordinary local model prompting would otherwise work. That is the principal rollout risk.

The previous broad pre-send gate blocked every message and was bypassed in #2790. This version reduces—but does not eliminate—that risk by keeping the signed-out path explicitly fail-open, making the blocked state visible before submission, and moving readiness to app startup rather than starting it after Run Task is clicked.

Important reviewer cautions:

• Do not replace the explicit signed-out/tokenless bypass with a global startup boolean.
• Do not key this behavior off requireSignin; optional-auth installations still contain both signed-out users (must be allowed) and signed-in users (must wait for their Den context).
• Do not re-enable editing or any send affordance while app-level connection state is non-ready.
• Do not consume auto-send markers or queued prompts while connection state is non-ready.
• Treat changes to projection strictness separately; relaxing it can send tasks without injected tools, while tightening it can lock out the signed-in cohort.
• A signed-in workspace whose Cloud MCP setup is explicitly disabled/removed currently remains blocked because it cannot satisfy the signed-in readiness invariant. Reviewers should confirm that product policy before this leaves draft.

What changed

• add a pure auth + background-maintenance state mapper for the pre-submit app barrier
• add a retry entry point to the existing session MCP maintenance lifecycle
• replace the prompt editor with a loading/reconnect state while signed-in startup is non-ready
• disable Run Task, Enter, steer, and queue before submission across existing-session and new-task composers
• hold auto-send and queued sends until the app-level connection is ready
• preserve drafts while the input is locked
• preserve a defensive no-send guard without doing connection work in submit
• keep signed-out and tokenless startup explicitly unblocked
• add focused regression coverage for the signed-in/signed-out state matrix

Focused checks

At current head 622361c87:

./bin/openwork-hub run mcp den-run-task-readiness -- pnpm --filter @openwork/app typecheck
passed

At readiness implementation revision 5800c1fe5:

./bin/openwork-hub run mcp den-run-task-readiness -- pnpm --filter @openwork/app exec bun test --isolate tests/cloud-mcp-submit-readiness.test.ts
10 pass, 0 fail

The readiness test was not rerun after the input-loading-only follow-up; the current head received the app TypeScript check instead.

Not yet verified

• live desktop input/loading and Run Task behavior
• end-to-end Den outage/recovery and Retry
• chat-first workspace creation followed by held auto-send
• real signed-in and signed-out distribution journeys
• broader app suite

The PR remains draft because a readiness false negative can lock the composer for all signed-in users. The live signed-in and signed-out journeys should be exercised before marking it ready.

[vercel]

@reachjalil is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jul 29, 2026 2:28pm