Pipa 0.5.6 — Mention-only mode

Pipa 0.5.6 — Mention-only mode

Ships mentionOnly, plus the CI fix that stops the intermittent Windows test failures. This text is what goes in the GitHub release and npm notes.

What is new

• Add an opt-in mentionOnly config flag. When true, Pipa only runs a turn for a message that directly @-mentions it, including threads it is already subscribed to. Absent or false keeps today's thread-following behavior, so this is fully backward compatible.
• pipa init asks for it, and PIPA_MENTION_ONLY (1/true/yes) sets it non-interactively.
• DMs stay ignored, unchanged: Pipa has never answered DMs and this flag does not alter that.
• Routines are unaffected; they call the executor directly rather than the Slack message path.

Thanks to @aovertus (Alexandre Overtus) for #48 — a clean, well-scoped first contribution with tests, docs, and a clear problem statement.

Reliability

• CI runs test files sequentially (--test-concurrency=1) and retries a failing test once (#49).
• The three isolated Managed restart tests now allow 120s instead of Node's 60s cap. They wait up to 45s for a spawned process, so 2-core Windows runners were failing them as testTimeoutFailure, which is what kept showing up as a different-looking flake.

Verification

• npm test: 216 passing on macOS, Linux, and Windows.
• npm run test:pack: passing.
• Live check on the real Slack app with the PR build: first mention answered, untagged follow-up ignored, later mention answered, and DMs still ignored.

Upgrade

npm install --global @usepipa/pipa@0.5.6
pipa --version

Existing installs keep the default behavior. To opt in, set "mentionOnly": true in ~/.pipa/config.json and restart. Do not rerun pipa init on an existing profile — it rewrites config.

Pipa 0.5.5 — Choose models from Slack

Choose the default model for new conversations directly from Slack, while existing threads keep their model and conversation history.

What is new

• Open your installation-specific command, such as /chopper model or /pipwick model, and choose a model from a private, provider-grouped picker. The selection persists across restarts.
• New or empty threads use the current default; existing threads retain their recorded model. New routines snapshot the default at creation; existing routines retain their saved selection.
• Export a token-free local Slack manifest template with pipa manifest to help upgrade an existing app.

Reliability fixes

• Picker submissions acknowledge promptly before background authorization and persistence. Model commands avoid waiting for optional profile enrichment that could expire the modal trigger.
• Socket Mode shutdown stops ingress and drains accepted acknowledgments with bounded cleanup.
• Legacy emoji and non-Latin installation names retain the /pipa fallback.
• Provider failures offer credential-safe guidance without silently switching models.

Upgrade

npm install --global @usepipa/pipa@0.5.5
pipa --version

Keep your existing profile and PIPA_HOME. To enable model commands on an existing Slack app:

1. Run pipa manifest to review the local template.
2. Merge the desired slash commands and commands bot scope into the existing Slack app, preserving custom settings.
3. Reauthorize that app. Keep existing tokens unless Slack rotates them; do not rerun pipa init.
4. Restart the same installation and confirm completion.
5. Open its model command, Save, wait for the private confirmation, and test in a new thread.

An npm upgrade alone does not update Slack registration. Prefer the unique named command: duplicate /pipa registrations route to the most recently installed Slack app. Existing threads retain their previous model after changing the default.

Verification

Full tests and installed-package smoke passed on merged release commit 185c954efac0f6aeaf234b1558fe0069c474b550. PR CI passed on Linux, macOS, and Windows after one retry for timing-test failures. The operator confirmed post-restart acceptance testing passed.

PR: #41

Full changelog: v0.5.4...v0.5.5

Pipa 0.5.4 — Slack bots and incoming webhooks

Pipa 0.5.4 — Slack bots and incoming webhooks

Pipa can now accept requests from explicitly allowlisted Slack bots and incoming webhooks, including an AWS Lambda posting an alert through a webhook and asking Pipa to act on it.

Thank you, Tolidano!

A big thank-you to @tolidano for contributing the Slack bot allowlist in #35, sharing the Lambda/webhook use case, and helping improve the setup documentation. Your contribution made this release possible.

What's new

• Configure permitted sender bot IDs with allowedSlackBotIds, the setup prompt, or PIPA_ALLOWED_BOT_IDS.
• An allowlisted bot or webhook can start a conversation by mentioning Pipa, then continue it in a subscribed thread.
• Authorization uses the Slack message's B-prefixed bot_id, including webhook messages without a U-prefixed user ID.
• Bot requests still obey channel restrictions. Unlisted bots, absent/empty bot allowlists, and Pipa's own messages are ignored.
• Setup guidance explains how to find the correct bot ID without installing Slack CLI, and why a webhook's bot ID can differ from its app's OAuth bot ID.

Upgrade

npm install -g @usepipa/pipa@0.5.4

Add trusted sender B IDs to allowedSlackBotIds, then restart Pipa to load the configuration. Bot access is opt-in; leaving the list empty does not allow all bots. DMs and external channels remain unsupported.

Verification

All 169 automated tests passed, along with the packaged CLI install/runtime smoke check. CI passed on Linux, macOS, and Windows. Live Slack verification covered human and app-bot conversations, real incoming-webhook mentions and replies, channel restrictions, absent/empty bot allowlists, and self-message rejection.

Documentation and release preparation: #38.

Full changelog: v0.5.3...v0.5.4

Pipa v0.5.3

Restart Pipa from Slack or the command line

Pipa can now restart itself without leaving you to bring it back online manually. Ask Pipa to restart, or run pipa restart; a detached helper completes the restart after the current process shuts down.

• Check the durable outcome with pipa restart --status.
• Return to the same Slack thread when Pipa is ready.
• Support Socket and Managed profiles on macOS, Linux, and Windows.
• Report failed or unconfirmed restarts instead of assuming they succeeded.

After upgrading an already-running Pipa, perform one manual stop and start before using self-restart for the first time.

Details

Full changelog

Publishing

Published @usepipa/pipa@0.5.3 to npm.

Pipa v0.5.2

Let long-running OpenCode work finish

Pipa no longer imposes executor-level deadlines on OpenCode turns, requests, event streams, or attachment reads. Explicit cancellation still works through same-thread replacement, routine deactivation or deletion, and pipa stop or shutdown.

• Remove Pipa-imposed executor timeouts.
• Ignore stale 404 permission replies so routines are not falsely marked blocked.

Details

Full changelog

Publishing

Published @usepipa/pipa@0.5.2 to npm.

Pipa v0.5.1

Preserve full Slack link destinations

Pipa now retains the underlying destination URL from shortened Slack rich-text links when it sends a request to OpenCode.

• Keep the full URL for shortened rich-text links, including Notion links.
• Preserve a URL when visible text contains a longer URL with the same prefix.
• Avoid duplicating URLs already present as complete tokens in the message.

Details

Full changelog

Publishing

Publish @usepipa/pipa@0.5.1 to npm manually, then publish this GitHub release.

Pipa v0.5.0

Put recurring work on autopilot in Slack

Pipa can now run one-time or recurring routines through your local OpenCode agent, then deliver the result to the exact Slack channel or thread you choose.

• Create, preview, edit, run, pause, and delete routines from the CLI.
• Schedule work once, daily, weekly, or monthly in an IANA timezone.
• Keep local-time schedules correct through daylight saving changes.
• Send each routine to a specific channel or existing thread, with a fresh OpenCode session for its replies.
• Safely recover routine state after restarts and avoid duplicate overlapping runs.

Details

Full changelog

Upgrade

npm install --global @usepipa/pipa@latest

Pipa v0.4.3

Start work only when OpenCode is ready

Pipa now waits for the local OpenCode workspace to finish starting before it accepts Slack work, eliminating a class of first-request failures.

• Check workspace readiness before the Slack runtime begins processing turns.
• Avoid sending a request to a server that is listening but not yet usable.
• Keep startup behavior more predictable after launching or restarting Pipa.

Details

Full changelog

Pipa v0.4.2

Supersede stale work safely

When a new message arrives in the same Slack thread, Pipa now gives the latest request priority instead of letting an older turn finish with stale output.

• Abort the in-progress work for that thread before starting the replacement.
• Keep unrelated Slack threads running independently.
• Stabilize status feedback and artifact delivery around interrupted turns.
• Improve the Managed setup guidance for people running a persistent local agent.

Details

Full changelog

Pipa v0.4.1

Make active Slack work easier to follow

This release makes long-running Slack turns feel more dependable while Pipa is working and when it returns files.

• Keep the right in-progress feedback on the active turn.
• Avoid stale success signals when a turn has been interrupted or replaced.
• Deliver declared artifacts more consistently alongside the agent's answer.
• Preserve the thread's delivery order when a response has multiple pieces.

Details

Full changelog