[nwm-54]

Why

Every polylane thread ask produced two identical user messages on the new thread. The API's thread create call already sends the prompt as the first user message (coreplanelabs/nominal#2516), and the CLI then posted the same prompt again as a separate message.

What changed

• thread ask no longer calls the messages endpoint after creating the thread; the prompt travels only in the create call.
• A new test records every request a --no-wait ask makes and expects exactly one POST to the threads endpoint.

Scope

• Covers thread ask only. thread continue posts to an existing thread, so its single messages call is correct.
• Leaves threads already created with duplicate messages as they are.

Blast Radius

Only the ask command changes. The server contract it now relies on is the same one the console has used since the create call started sending the first message.

Verification

• Before the fix, running the installed CLI against a test workspace created a thread with two user messages 211 ms apart, then one assistant reply.
• After the fix, running the patched source against the same workspace created a thread with one user message and one assistant reply, and --verbose showed a single POST.
• npm run test: 623 pass, 0 fail. npm run lint: clean. tsc --noEmit reports two errors in the integration connect command on main as well, from spec drift unrelated to this diff.

🤖 Generated with Claude Code

[polylane]

Warning

Polylane could not verify the production impact of this pull request.

I checked nominal-api-threads-prod: 99,444 requests over 72h at about 1,184/hour, zero errors. The prompt is not lost — threads.post sends the first user message server-side (nominal#2516, merged 2026-09-10) and the CLI still passes prompt in the create call.

Mermaid not needed: this is a single-line deletion on a client, with the server contract unchanged.

Reasoning: src/commands/thread/ask.ts deletes one line, await api.messagesPost({ workspaceId, threadId: thread.id, prompt });. The create call at ask.ts:55-61 already carries the prompt, and the API route apps/apis/api-threads/src/routers/threads/post.ts builds and sends the first user message during creation (buildFirstUserMessage). Removing the follow-up POST is correct, not a degradation.

Check	Result
Impact assessment	Production impact not verified
Security review	Passed · 1 ruled out

View the full analysis →

Also considered · 1 refuted

• Refuted · Removing the client-side messages POST drops the prompt and leaves an empty thread · threads.post already sends the first user message server-side: apps/apis/api-threads/src/routers/threads/post.ts imports buildFirstUserMessage (line 22) and sends it during create, shipped by nominal#2516 (merged 2026-09-10, console relies on it).

Analysed against 8 cloud accounts and 1 repository

• Cloud accounts: coreplane-prod, baseberry-uat, coreplane-infra, coreplane, coreplane-gtm, 251714435813, Polylane, nominal-493716
• Repository: coreplanelabs/cli

Polylane could not find the cloud resources this repository manages, so this review looked at the entire cloud account. Connect this repository to its resources and the next review will focus on exactly what this code deploys to.

_{Polylane analysed f9910fb for production impact and security. You can ask follow-ups by mentioning @polylane in a comment.}