The Verification Code Went to the Right Phone and the Wrong Person

2026-09-06

Every growing team eventually acquires one of these: an old Android phone, sitting in a drawer or passed between desks, whose only job is to receive a text message. It's the number on file with the bank. The number tied to the Google Workspace admin account. The one WhatsApp Business uses, or the one the payment processor calls when it wants to confirm a payout. Nobody remembers exactly why that particular device became "the verification phone," but it did, and now everyone depends on it.

The trouble shows up the moment a code needs to be typed in under a two-minute window, and the person who needs it isn't near the drawer. Maybe it's a Friday afternoon and finance is trying to close out a transfer. Maybe onboarding a new payment gateway account falls to whoever's at their desk, and that happens to not be the person sitting next to the phone. The code arrives exactly where it's supposed to — and exactly nowhere useful.

Why the DIY fixes don't hold up

A predictable pattern shows up when people try to solve this themselves: point a Tasker profile or an IFTTT applet at the phone's SMS inbox and have it forward texts automatically. It used to work reasonably well. Then Google tightened the SMS and call-log permission rules for Android apps, restricting that kind of broad SMS read access to apps registered as the device's default SMS handler. IFTTT's own SMS-based triggers on Android have been unreliable for exactly this reason for a while now, and Tasker-style automations that used to read incoming texts freely often stop working after an Android or Play Services update, with no clear warning why.

Purpose-built tools exist too, and it's worth being specific about how they differ. AutoForward Text, for instance, is built to send a copy of one phone's texts to another phone — useful for parental monitoring or device migration, but not aimed at routing a message into Slack or a team inbox. smstoslack.com does that exact job, and does it well for a single-purpose case, but it doesn't extend past Slack itself if a team also needs email or a webhook into its own backend.

Forwarding as automation, not a phone swap

Pushferry treats the drawer phone as a device to automate, not a number to replace. Install the app on it, and every incoming SMS gets forwarded — to Slack, to Discord, to an email address, to a webhook, or straight into a REST API if there's a custom workflow to build around it. The 2FA code meant for finance shows up in the finance channel. The one meant for whoever's on call that week shows up wherever on-call actually pays attention. Nothing changes on the sending side — the bank, Google, the payment processor never see a difference, because there isn't one. It's still the same SIM, still the same number, just no longer chained to a physical location.

Replies work the same way: if a confirmation needs to be texted back, it goes out from that real phone number, not from some intermediary service standing between the request and the account it belongs to.

Getting it running costs nothing to try

The free tier covers exactly this scenario — one phone, unlimited forwarding, no card required to start. For a team with a single shared verification phone, that's usually the whole problem solved. Paid tiers only come into play once there's more than one device to connect, and pricing scales with the number of phones, not with how many codes pass through them in a month. A busy verification phone and a quiet one cost the same to run. The point was never to meter the messages — it was to get the code to the person who's actually waiting for it.