fix(create-thread): unarchive thread after creation so it lands in author's Inbox

[jgalea]

Problem

Twist auto-archives newly-created threads for the author. When create-thread is called by an agent (or any client running as a user), the thread never appears in that user's Inbox by default — they have to find it via the channel view or URL.

This makes the existing tool behavior surprising for anyone using this MCP to drive an agent that posts on the user's behalf — the user never sees their own outgoing posts in their Inbox alongside everyone else's.

Fix

After client.threads.createThread(...), call client.inbox.unarchiveThread(thread.id) so the new thread lands in the author's Inbox alongside the recipients'. Wrapped in try/catch — unarchive failure is non-fatal, the thread itself was created successfully and recipients still get notified.

Also updates the trailing user-facing note from "Threads you create do not appear in your own Inbox by default…" to a confirmation that it's now there.

Tests

Snapshots updated for the two create-thread test cases. All 156 tests pass.

Test Suites: 17 passed, 17 total
Tests:       156 passed, 156 total
Snapshots:   46 passed, 46 total

Notes

• No new dependencies.
• client.inbox.unarchiveThread was already exposed in @doist/twist-sdk (used elsewhere in the codebase).
• Verified against a real Twist workspace before this PR — newly-created threads now appear in the author's Inbox view.

[scottlovegrove]

@jgalea Whilst I understand the reasoning behind this PR ( believe me I do 😄), I'm relcutant to change the default (read: expected Twist) behaviour here. Perhaps we can have some middle ground where we have an option displayInInbox that can be set true (default: false), and when true, then it can do this new behaviour.

[scottlovegrove]

@jgalea Just to let you know, I've taken inspiration from this PR and have added the same functionality (behind an option, but with the ability to set a default) to our Twist CLI (PR)

[jgalea]

Thanks Scott, fair call. Default-preserving with opt-in is the right move, and the symmetry with the Twist CLI option pattern works well.

I'll restructure as:

• Add a displayInInbox boolean parameter to create-thread (default false, matching Twist's standard behavior).
• When true, the post-create unarchiveThread() call fires; otherwise the existing behavior is preserved.
• Snapshots and tail-note revert to the original wording for the default case, with a new test covering the opt-in branch.

Quick question on the default override: your CLI exposes both a per-call option and a settable default. For this MCP, would you prefer (a) just the per-call parameter, or (b) per-call + an env var (e.g. TWIST_CREATE_THREAD_DISPLAY_IN_INBOX=true) so a deployer can flip the workspace-wide default without changing every call? Happy with either, (b) maps closer to your CLI's UX, (a) is simpler.

I'll push the revision once you've picked.

[scottlovegrove]

Quick question on the default override: your CLI exposes both a per-call option and a settable default. For this MCP, would you prefer (a) just the per-call parameter, or (b) per-call + an env var (e.g. TWIST_CREATE_THREAD_DISPLAY_IN_INBOX=true) so a deployer can flip the workspace-wide default without changing every call? Happy with either, (b) maps closer to your CLI's UX, (a) is simpler.

Actually, I think providing an environment variable would be fine, especially for those running the MCP locally. Just note that for the remote MCP, this value will be unset, so if you're using the remote MCP, you will not be able to set the default.

Be sure to keep the README updated with the environment variable so that it can be surfaced for other users, with a note explicitly saying that the variable is only for running it locally, and the remote MCP will not have the default value set.