How to

NOISEY posts to social apps from real phones — handsets plugged into your own computer — instead of from an API or a browser pretending to be a phone. You drop a video into a folder, and a rule you wrote posts it through the app on the phone you chose.

It has two halves: the desktop app on your Mac, which physically drives the phones, and this account area on the web, which holds your folders, automations and media and tells the desktop app what to do.

The desktop app is the executor: it mirrors your phones live, taps and types on them, and runs your routines. It is the only thing that ever touches a handset — NOISEY's servers never do.

The website (my.noisey.app) is the control panel: folders, the webhook that feeds them, automations, activity, and your account. When an automation fires, the server queues a job and hands it to your desktop app, which does the actual posting.

Go to my.noisey.app/signup. You need a name, an email and a password — or use Continue with Google, which needs neither password nor confirmation step. Nothing else is collected, and no card is asked for.

Email accounts must confirm their address before the first sign in — check your inbox for a message called Confirm your email address and click the link. Until you do, signing in answers “confirm your email address first”.

No email? Check spam, then sign up again with the same address to trigger a fresh link. Google sign-ins skip this entirely.

The download button on noisey.ai signs you in first, then lands on the dashboard's Get the Mac app card, which holds the .dmg. That order is deliberate: every copy of NOISEY belongs to an account from its first launch, because your plan's limits count per account.

First launch: NOISEY isn't notarised with Apple yet, so macOS shows its unidentified-developer prompt. Right-click the app in Applications, choose Open, and confirm — once. Every later launch is normal.

• A Mac on macOS 13 or newer — Apple silicon or Intel.
• One or more Android phones and a USB cable per phone (a powered hub once you pass a handful).
• An account, which is free to start.

Windows is on the roadmap but not shipped. iPhones are not supported.

1. Create an account and download NOISEY for Mac.
2. In the desktop app, choose Connect this computer and approve the code at my.noisey.app/link.
3. Plug in a phone with USB debugging on and accept the trust prompt on its screen.
4. Teach the desktop app a routine — for example, how you post a video to TikTok — and give it everything it needs so it can run unattended.
5. On the web: make a folder under Media, create your webhook, then under Automations wire folder → routine → phone.
6. POST a video at the webhook with ?folder=your folder — and watch Activity.

1. In the desktop app, press the Connect this computer button — it sits in the top bar (and fills the first screen) whenever the app isn't signed in. A short code like ABCD-2345 appears and the app starts waiting.
2. Your browser opens my.noisey.app/link — sign in if you aren't already, and the code carries through.
3. The page names the computer that is asking. If it's yours, press Connect it; the app signs itself in within a few seconds.

The app never asks for your password, so changing it later — or adding Google sign-in — changes nothing on the desktop side.

Codes are short-lived on purpose and die on their own after a few minutes. Go back to the desktop app and ask it to connect again — it mints a fresh code instantly. Nothing about your account changed.

Press I didn't ask. The only way a code reaches you is that someone ran the connect flow and got the code to you — and if that someone wasn't you, approving it would sign their computer into your account, with access to your phones, media and automations.

Declining burns the code permanently. Nothing is connected, and the code cannot be retried.

Settings → Your computers lists every machine connected to the account, with when it was last seen. Sign it out takes effect immediately: that computer stops syncing and stops receiving jobs. It keeps driving the phones plugged into it locally — signing out severs the account, not the hardware in the room.

Yes — deliberately. Driving phones that are plugged into your own computer never requires a server, so mirroring and manual control keep working with no connection at all.

What pauses is the cloud half: sync, webhook-fed media, and server-queued jobs. Those queue up server-side and dispatch when the app is back online.

1. Enable USB debugging on the phone (next question).
2. Plug it into the Mac running NOISEY.
3. On the phone's screen, accept Allow USB debugging? — tick Always allow from this computer so it survives replugging.

The phone appears in the desktop app's grid and registers itself to your account, so it also shows under Phones on the web a moment later.

1. On the phone: Settings → About phone, tap Build number seven times. It announces you are now a developer.
2. Back in Settings, open Developer options and switch USB debugging on.

The menu names vary slightly by manufacturer, but the seven-taps-on-build-number ritual is universal Android.

The phone hasn't trusted your computer yet. Unlock it and look for the Allow USB debugging? prompt — it hides easily, and replugging the cable makes it reappear. Tick Always allow from this computer and accept. If the prompt never shows, revoke USB debugging authorisations in Developer options and replug.

• online — connected to your computer and ready.
• busy — a job is running on it right now.
• offline — registered to the account but not currently attached to a running desktop app.
• unauthorized — attached, but the phone hasn't accepted the USB debugging prompt.
• error — the desktop app can see it but can't drive it; replugging usually clears it.

Until a phone carries a profile it is named by what it is — its model, falling back to its hardware id. Assign a profile to the handset in the desktop app and it is named by who it posts as, which is the name that actually matters.

The free plan registers up to 2 phones; the paid plan up to 10. The count is per unique handset, not per cable or address — replugging, hubs and address changes never double-count a phone. The limit is enforced when a new handset registers, and the desktop app tells you when you hit it.

Under Phones: click a phone's name to rename it, or press Name all phones and every unnamed handset takes the next name from a fixed list — Onyx, Ember, Indigo, Basalt… — deterministic, memorable, and editable after.

The name is canonical: the desktop app shows the same word on the same tile, and renaming there writes back here. “Post to Onyx” routes; “post to the ninth SM-G986U” does not.

A named set of handsets an automation targets as one — “Morning rack”, say. When the automation fires, every phone in the group gets the job, spaced by the stagger you set.

Groups are made where they're needed: in the automation form, choose Several phones…, tick the handsets, name the group. It is saved and reusable by later automations.

A queue with a name. Files land in a folder — through your webhook or a watched Drive folder — and automations watch folders. That binding, folder to automation, is the entire routing model: where a file lands decides what happens to it.

Media → New folder, or inline while creating an automation. A folder is just a name — there is nothing else to configure on it.

Two ways today:

• Your webhook — anything that can POST a file (n8n, Zapier, Make, a script, a render pipeline) sends it to your webhook URL and names the folder.
• A watched Google Drive folder — NOISEY checks it every few minutes server-side and pulls in new videos.

There is deliberately no manual upload button yet — NOISEY is plumbing between where your videos are made and the phone that posts them.

One URL, unique to your account, that accepts video uploads:

POST https://api.noisey.app/webhooks/media/<your-token>?folder=Morning posts

Create it under Media → Your webhook. The long token in the URL is the credential — anyone holding the URL can feed your account, so treat it like a password.

Name it in the request. Add ?folder= with the folder's name (case doesn't matter), its path for a nested one — ?folder=Clients/Acme — or its id; an x-folder header works too. One webhook serves every folder, so an n8n or Zapier flow feeding three folders is one secret and a field, not three URLs.

An unknown folder name is refused with a clear error rather than silently creating a folder no automation watches — make the folder in the dashboard first. Leave ?folder= off entirely and the file lands unfiled.

Media → Your webhook → Copy URL — the working URL is copyable there any time. It is stored encrypted under the server's own key, so a leaked database alone still reveals nothing. Webhooks made before copying existed say so on their row; recreate those once and they are copyable forever after.

Media → Your webhook → Revoke. It takes effect immediately: the old URL starts answering 404 on the next request. Then create a new webhook and update your integrations. Nothing already ingested is affected — a webhook token can only add files, never read or delete anything.

By design. Files are fingerprinted by their content, and bytes NOISEY has already seen are recognised, not re-ingested — the webhook answers with "deduped": true and fires no automations. A Drive re-sync or a retrying pipeline must never post yesterday's video to twenty phones a second time. Genuinely new content — even a one-frame change — is a new file and triggers normally.

NOISEY is a conveyor belt to posting, not storage. On the free plan a file lives 24 hours from upload — post it before the clock does; each file's countdown shows under Media. The paid plan ($29/month) keeps files 90 days. Your plan also caps how many are held at once (30 free, 500 paid). Keep the originals wherever they were made.

Yes — when creating a folder, choose which folder it lives inside. Nested folders show as paths (“Clients / Acme”) everywhere, and the webhook reaches one the same way: ?folder=Clients/Acme. Each folder is still its own queue — an automation watches exactly one.

The bin icon on the folder's card. Folders nested inside it go too. Files are not deleted — they move to “No folder” and keep answering to their own retention clock. A folder an automation watches (itself or through a nested folder) refuses to be deleted and names the automation, so a tidy-up can never silently kill the thing that posts at 9am.

Yes — every file listed under Media has a download link. It streams you the exact bytes that were ingested.

A standing rule: when a file lands in this folder, run this routine on this phone (or group), with the new file as its subject. The moment your webhook or a Drive sync delivers a new file into the folder, the automation queues one job per target phone — no clicking, no being at your desk.

1. Automations → New automation.
2. Pick the folder that triggers it — or create one right there.
3. Pick the routine to run. Only routines that can run unattended are offered.
4. Pick one phone, an existing group, or Several phones… to make a group on the spot.
5. For groups, set the seconds between phones, name it if the suggestion doesn't suit, and create. It starts enabled.

Three things: a folder (made on the web in seconds), at least one phone registered, and a routine that can run unattended — routines are taught in the desktop app and sync up automatically once your computer is connected. The Automations page tells you which of the three is missing and where to get it.

It sweeps the automation's folder by hand — newest files first, up to a sensible cap — and queues jobs exactly as if those files had just arrived. It reports what it queued and, if the cap left older files behind, says how many, rather than pretending it covered everything.

Three explanations, in order of likelihood:

• Every file in the folder has already been queued or posted by this automation on those phones — the same video is never double-posted (see below).
• The folder is empty.
• The automation is paused — resume it first.

Not by the same automation on the same phone. Every job is keyed by automation × file × phone, and a combination that already has a queued, running or successful job is skipped — by webhook triggers and by Run now alike. The one exception is a failed job: that combination may be retried, because the post never happened.

When an automation fires on a group, each phone's job is scheduled that many seconds after the previous one instead of all at once. Twenty phones uploading simultaneously through one computer is a self-inflicted traffic jam — the spacing is a courtesy to your own bandwidth and your own machine, nothing more.

Both live on the automation's card. Pause keeps the rule but ignores new files until you resume — arrivals while paused are not queued retroactively. Delete removes the rule; jobs that already ran, and their history, are untouched.

One on the free plan — enough to prove the loop end to end — and unlimited on paid. The limit is on standing rules, not on how often they fire.

In the automation form, switch the trigger from When a file lands to On a schedule: pick the times, the weekdays, and the folder to draw from. Each fire posts the newest file that phone hasn't posted yet — one per phone per fire, so a daily schedule advances one post a day and never re-posts.

Times run in your timezone, and the card shows the next run so you can check the schedule before it matters.

A late-start bound. “9:00, window 30” fires at 9:00 when everything is up; if your Mac or the tick is catching up it may start as late as 9:30; after that the run is recorded as missed rather than posting stale at 14:37. It is a reliability bound, not a randomiser — starts are never shuffled inside the window.

Its start window closed before your Mac was connected and free. Nothing broke and nothing posted — the file is still there, and the next scheduled fire picks it up. If runs keep missing, the Mac isn't open at those times, or the window is tighter than your mornings; widen it on the automation.

Walk the chain — each link is visible:

1. Media: did the file actually land, and in the folder the automation watches? A ?folder= typo is refused by the webhook with an error your sending tool logged.
2. Was it genuinely new? Identical bytes are deduped and fire nothing.
3. Automations: is the rule enabled, and watching that exact folder?
4. Activity: is there a job? If it says queued, the server did its part and is waiting for your desktop app to be open and connected. If it says failed, the error is printed under it.

A repeatable task you teach the desktop app in plain words — “open TikTok, start a new post, pick the newest video, write the caption, post it”. NOISEY works out the taps and typing on the actual handset. Automations and schedules then run that routine without you.

In the desktop app, with a phone connected: describe what you want done and run it. Refine the instructions until it behaves, save it with a name, and it syncs to your account automatically — a moment later it is offered on the web when you create an automation or a schedule.

Yes — in the automation form, press Write one next to the routine picker: a name and plain-word steps, one per line. Your Mac adopts it the next time it connects; until then the routine is labelled waiting for your Mac and anything scheduled against it simply waits too.

Write concrete values rather than placeholders — a scheduled run has nobody to ask. The first run on the phone thinks its way through; let it learn in the desktop app and replays become free.

A learned routine has been distilled into exact steps, so replaying it costs nothing and is fast — that's “(free)”.

An unlearned routine asks the AI to work the task out fresh every run — flexible, but slower and it spends model usage each time. Run a routine successfully in the desktop app and let it learn, and it moves to the free kind.

Because it asks a question at run time. A routine whose input is set to ask each run needs a human answer, and nobody is there at 9am — so it cannot run unattended and is left out of the list (the page says how many were hidden and why). In the desktop app, give that input a fixed value — or take it from the incoming video — and the routine becomes schedulable.

Routines live on the Mac that taught them, and the same routine name on two Macs is genuinely two files that can differ. The machine name — “Post to TikTok — Studio Mac” — tells you which computer will be doing the work, which matters the day you run two.

In the desktop app, where it was made — edit the instructions or its inputs and save. The web picks up the new version automatically through the same sync that delivered it. There is no routine editor on the web, deliberately: a routine can only be tested against a real phone, and the phones are in front of your Mac.

1. Add an HTTP Request node where your flow has the finished video (as binary data).
2. Method POST; URL: your webhook URL plus ?folder=Morning posts (the folder is the only routing decision, so make it an expression if your flow feeds more than one).
3. Body content type: n8n binary file, pointing at your binary property.
4. Add a header x-filename with the file's name — it is how the upload is labelled in Media.

The node's response tells you what happened: jobsQueued above zero means phones are about to post.

The same shape as n8n: a raw HTTP action (Zapier's Webhooks by Zapier → Custom Request, Make's HTTP → Make a request) POSTing the file as the body to your webhook URL with ?folder= naming the folder and an x-filename header. Send the file's bytes as the raw body — not a form or JSON wrapper.

curl -X POST \
  -H "content-type: video/mp4" \
  -H "x-filename: sunrise-take-1.mp4" \
  --data-binary @sunrise-take-1.mp4 \
  "https://api.noisey.app/webhooks/media/<your-token>?folder=Morning posts"

--data-binary matters — plain -d mangles binary data. The Media page offers this exact command, filled in, when you create your webhook.

Request:

• POST with the file's bytes as the raw body — streamed, so large videos are fine.
• content-type — the file's type, e.g. video/mp4.
• x-filename — what to call it (optional; a timestamped name is invented otherwise).
• ?folder= (or x-folder) — folder name or id (optional; unfiled otherwise).

Response, on success:

{
  "media": { "id": "…", "filename": "…", "size_bytes": 1234567, … },
  "automationsTriggered": 1,
  "jobsQueued": 2
}

A repeat of known bytes answers "deduped": true with nothing triggered. An unknown ?folder= is a 404 with a message naming the folder; a revoked or mistyped token is a 404 saying so.

1. Sources → Watch a folder (at my.noisey.app/sources).
2. Connect the Google account the videos live in, and allow Drive when asked.
3. Browse to the folder — you pick it by looking at it, not by pasting an id — name what it feeds in NOISEY, and confirm.

New videos appearing in that Drive folder are pulled into the NOISEY folder you chose, where they trigger automations exactly like webhook arrivals.

Because they are different permissions and you should only grant what you use. Signing in shares your name and email; Drive access is requested the moment you connect a folder, and not before. NOISEY reads the folders you browse and downloads the videos it ingests — it never writes to, or deletes from, your Drive.

Google occasionally invalidates a connection — a password change or a security review on their side does it. The source keeps its configuration and shows the error loudly instead of failing quietly; open Sources, reconnect Google when prompted, and syncing resumes where it left off.

Watching happens on NOISEY's servers every few minutes, so files are ingested and jobs queued with your Mac closed. The posting itself still needs the desktop app open with the phones attached — queued jobs wait and dispatch the moment it connects.

The person a phone posts as: a name, a handle, a picture, the platform, and optionally a brief describing the account holder. Assign a profile to a handset in the desktop app and everything stops calling it SM-G986U1. Profiles live at my.noisey.app/profiles.

Schedules belong to profiles: open Profiles, pick the profile, and add times and weekdays. Each slot names the routine to run and the folder to draw from, and fires on whichever phone carries the profile — in your timezone.

Like automations, schedules need a routine that runs unattended, and the profile must be on a phone. The page shows the next scheduled run so you can see it is armed.

A short description of the real person who holds the account — written by you, never generated — that routines can use for context, so a fitness coach's captions don't read like a barber's. It is optional, and it only ever describes an actual account holder.

Settings → You. The picture is squared and shrunk to 128px in your browser before it is saved — it is only ever shown small, so nothing large ever leaves your machine. The name is whatever you want to be greeted as.

Settings → Email: type the new address and press Change. A confirmation link goes to the new inbox, and nothing changes until it is clicked — an unconfirmed typo can't lock you out. Afterwards you sign in with the new address.

Settings → Password, with your current password in hand. The sign out my other sessions box is ticked by default — changing a password because it leaked should also evict whoever is using it. Your current browser stays signed in either way.

Yes. Settings → Password recognises a Google-only account and offers to email you a link to set one. Once set, both ways in work — useful the day Google sign-in is unavailable on some machine.

my.noisey.app/forgot-password emails you a reset link. If no email arrives, check spam, and check you typed the address the account was made with — the page deliberately doesn't reveal whether an address exists.

Settings → Sessions → Sign out everywhere else. Every browser session except the one you're in ends immediately. Desktop apps are separate — they are listed under Your computers on the same page, each with its own Sign it out.

There is no self-serve deletion yet. Write to support@noisey.app from the account's address and it will be removed, along with its media, devices and automations.

2 phones, 30 stored uploads, 1 automation, 7 days of activity history, and files live 24 hours from upload — enough to run the whole loop for real on a small setup, provided you post what you ingest. Every account starts free, and no card is ever asked for at signup.

$29/month raises the caps to 10 phones, 500 stored uploads, unlimited automations and 90 days of history — and files are kept 90 days instead of 24 hours. Upgrading from inside the app is on its way but not live yet — today every account runs on the free tier.

The action is refused, loudly and at the moment you try it — “automations limit reached (1/1)”, say — and nothing you already have is touched. Limits are enforced on the server, so they read the same everywhere.

• An unconfirmed email account is told to confirm first — check the message above the form, and your inbox.
• Very strict browser privacy modes that block all cookies will block the session cookie too; allow cookies for noisey.app.
• If the page says it could not reach the server, that's us, not you — try again shortly.

The Google door is temporarily closed on the server — the email and password form underneath is unaffected, and an account made with email can add Google later. If you only ever signed in with Google, use Forgot your password to set one and get in that way.

Queued means the server is holding jobs for a desktop app that isn't there. Open NOISEY on the Mac the routine lives on, signed in to the same account, with the target phones attached and authorised — dispatch happens within seconds of it connecting. Check Settings → Your computers shows the machine as recently seen.

Activity prints the error under the job, in red, with the attempt count. Failures are never swallowed: a failed post is eligible to be re-queued (the double-post guard deliberately excludes failures), so fixing the cause and running the automation again retries it.

• Swap the cable — charging-only leads are everywhere.
• Confirm USB debugging is on and the trust prompt was accepted (unlock the phone; replug to resurface it).
• Try another port, or plug direct instead of via a hub.
• If the desktop app sees it but the web doesn't, check the app is signed in — the phone registers to your account through it.

The error body says which of the two it is:

• unknown or revoked token — the URL is mistyped, stale after a revoke, or truncated by the tool sending it. Create a fresh webhook and paste carefully.
• no folder called “…” — the ?folder= value doesn't match any folder on the account. Create the folder first, or fix the spelling; matching ignores case but not typos.

The desktop app has a bug button at the foot of its sidebar — reports filed there arrive with the app version and platform attached, which halves the round trips. For anything on the web, email support@noisey.app with what you did, what you expected, and what happened instead.

No, structurally. Phones are attached to your computer, and only the desktop app can drive them; the server stores rules and media, queues jobs, and hands them to your app. A compromised server could not tap a screen — there is no path from it to a handset that doesn't run through software on your own machine.

The token is generated with a cryptographically secure generator. Requests are verified against a stored hash — the same discipline as passwords — and the copyable value is kept encrypted at rest so Copy URL works without weakening that. A leaked token can only add files to your account (never read, delete, or post), and revoking it takes effect on the next request.

The desktop app never handles your password; it shows a short-lived code you approve while signed in on the web. The approval page leads with the asking machine's name and makes I didn't ask as prominent as approval — the only real attack is talking you into approving somebody else's code, and the page is built to make that question unavoidable.

Your account (name, email, hashed password or Google identity), your folders, automations, profiles and schedules, the videos you ingest for as long as they live, job history per your plan, and per phone an identifier, model and status — no phone contents. Drive access, if you grant it, is used to read the watched folder and nothing else. The full inventory, with retention times and your rights over all of it, is the privacy policy.

At noisey.ai/terms, with the privacy policy at noisey.ai/privacy. You agree to them when you create an account. The short shape: NOISEY is provided for research, testing and the automation of phones and accounts you own or are authorised to manage — what your automations do is your responsibility, the way it works with any automation tool.

You are. NOISEY executes the routines you author, on your phones, against your accounts — we do not review, approve or control them, and we cannot see your reasons. That also means the platforms you post to are a relationship between you and them: their rules apply to you directly, and enforcement they take (including account restrictions) is yours to carry. The terms of service spell this out.

A routine is what a phone does — tap this, type that, check it worked. You draw it on a canvas at Routines.

An automation decides when a routine runs — when a file lands in a folder, or at nine every weekday.

A flow is everything around that — something happens, a model has an opinion about it, and one or more things follow. Running a routine is one of the things it can do; calling a webhook or writing to your timeline are others.

They stay separate so the simple case stays simple. “Post what lands in this folder” should not require drawing a diagram.

Routines → Draw a routine. Pick steps from the palette on the left, then drag from the dot under one box to another to say what happens next. The box marked Start is where it begins.

Saving checks the wiring. An edge pointing at nothing, a box nothing reaches, or a step this version cannot run is refused there and then — better than finding out at three in the morning on a phone.

Use Pick it off the phone in the inspector. With a phone connected, it shows you that phone’s screen as it is right now, outlines everything NOISEY can identify, and you click the thing you mean. It works out the most durable way to find it again — its id first, then its accessibility label, then its text. If the best available name is a generic one, it says so, because a name like button2 matches whichever button happens to sit second and will press something else on the next handset.

Yes — Run it once at the bottom of the editor. It saves, then runs on the phone you choose, and the boxes colour in as it goes: green where it worked, red where it stopped. The step that stopped it carries a picture of the screen at that moment, which is usually the whole answer.

Add an Ask a model step. It uses your own AI account — NOISEY does not resell model access — so you pay your provider directly and nothing else.

Your Mac keeps its key in the macOS keychain. Flows run on our servers so they keep working overnight, which is out of reach of that keychain, so you can optionally store a key with us under Settings. It is encrypted, never shown again, and deleting it takes one click. Without one, a flow simply stops when it reaches an AI step.

There is a monthly ceiling on AI steps per account, checked before each call rather than discovered on a bill. Settings shows how many you have used.

Yes — the Call a URL step. Public addresses only: a flow cannot be pointed at localhost, a private network range or a cloud metadata address, because the request is made by our servers rather than your browser and that would let one account reach things it should not.

It notices engagement. Without it a flow can act on a schedule or a file; with it, a flow can react to somebody commenting on your client’s post. It is an Android app you install on your own handsets over adb.

It reads notifications from six apps: LinkedIn, TikTok, Instagram, X, Facebook and YouTube. That list is built into the app. It cannot be widened by a setting, by us, or by anyone else — only by a new version you choose to install.

It will never read:

• messages and SMS, including WhatsApp, Telegram and Signal;
• your dialer, or mail;
• banking, payment and wallet apps;
• authenticators and password managers;
• Android’s own system notifications.

That exclusion is checked before the permitted list, so a mistake in one cannot open the other. Anything shaped like a verification code is thrown away on the phone, before it is written down or sent anywhere. And it cannot reply to, open or dismiss a notification — it only reads.

Install the APK over adb, open it, and use the button to open Android’s own Notification Access screen. You grant it there, by hand. NOISEY will not grant it for you — an app that silently gives itself notification access is not one you should trust.

Revoke it the same way, in Android Settings, at any time. The app itself shows whether access is granted and how many notifications are waiting for your Mac to collect.

The app has no internet access at all. It writes to a file on the phone; your Mac collects it over the same cable it already uses to drive that handset, and passes it to NOISEY so your flows can react. Contents are deleted after 72 hours.

You get a copy on your own account. It is yours from then on — if the author publishes a newer version, what is already running on your phones does not change until you install the update. Anything the author filled in for their own account arrives blank, so set your own values before running it. An installed flow arrives switched off.

The steps, and nothing you filled in. Before publishing, NOISEY shows you the exact list of what it will strip:

• any text a step types, unless it is a {{placeholder}};
• the values you set for the routine’s inputs;
• the phones, groups and folders it was pointed at;
• headers on any webhook step, which often carry keys.

A webhook URL with something that looks like a token in it is refused outright rather than quietly emptied — publishing it would publish the token, and an emptied one would ship a flow that looks complete and does nothing.

The same line the product itself draws: nothing whose purpose is helping automation avoid being detected or enforced against. Staff remove what breaks that, and repeat offenders lose the ability to publish. Report anything that crosses it, or write to support@noisey.app.

A forum inside the app — threads and replies under a handful of topics: announcements, automations & routines, phones & hardware, feature requests, show & tell. It is for people who run NOISEY to compare notes. You need to be signed in to read or post; there is no public, anonymous side.

Your display name and the avatar from your settings — never your email address. If your account has no name yet, the composer asks you to pick one before your first post. Change it any time in Settings; posts show the current name.

Short list, firmly held:

• Keep it lawful, and keep it civil. No harassment, no abuse.
• No spam — one thread per idea, no self-promotion floods.
• No detection-evasion techniques. Anything whose point is helping automation avoid being caught by a platform — anti-ban tricks, fingerprint spoofing, “undetectable” methods — is removed, the same line the product itself draws. Reliability engineering (retries, waits, spacing) is fine to discuss.
• No other people’s personal information, and nothing confidential.
• Everyone here is 18 or over — it is in the terms.

Staff remove what breaks these rules and ban accounts that keep breaking them. The full version lives in the terms of service.

Every thread and reply has a Report button. Pick a reason, add a note if it helps, and send — it lands in a staff queue that shows the content in context, and one decision there resolves every report on the same post. If you would rather write it down, or you want to appeal a moderation decision, support@noisey.app reaches a person. Illegal content is removed when we identify it and may be reported to authorities where the law requires.

Yes, both, on your own threads and replies. Edits show a small “edited” marker. Deleting a reply leaves a “removed by its author” tombstone so conversations keep their shape; deleting a thread takes its replies with it. Content staff removed for a rule breach is kept internally as the moderation record but is never shown again.

Announcements is where NOISEY posts release notes and news — staff start those threads, and anyone can reply under them. Every other topic is open. Pick the one that fits; staff occasionally move or pin things so the useful stuff stays findable.

Staff locked it — usually because it is answered, or because it stopped being useful. Locked threads stay readable; they just take no new replies. If you think a lock is wrong, support@noisey.app.

One new thread every two minutes, one reply every ten seconds. Plain anti-flood plumbing — it keeps a stuck script or a paste-happy afternoon from burying everyone else’s conversations. Wait out the timer it shows you and post again.

Not yet — posts are text, and links work. Text keeps the forum fast and keeps moderation honest at the current size. If you need to show something, host the image elsewhere and link it. (Your Media library is separate: that is private storage for the videos your automations post.)

Three sections in the left rail — Phones, Media and Routines — with your groups and the panels for the current selection under them. Phones carries a count of ready handsets, Routines a count of saved routines.

Activity and Settings are the two icons at the far right of the top bar rather than rail items: they are places you visit, not things you do. Both toggle, so pressing again puts you back on Phones. The foot of the rail always carries the adb status and the bug button; tick some phones and a batch bar appears under the grid.

The ones you have ticked — not the one you happen to be looking at. The Phones list in the panel, the batch bar, the Toolbox and Claw all read the same selection, and the Phones header states it as N/M with All and None underneath. Clicking a tile's header ticks it too.

Worth knowing before you press anything: a phone that connects is ticked automatically. Plug a handset in mid-session and it has quietly joined the target of your next batch action.

Almost always one of four preconditions:

• A phone selected — most of the app.
• Exactly one phone — recording.
• This computer connected to your account — sync, profiles, and jobs sent by the server.
• A live mirror session on that phone — typing as keystrokes, and any text outside ASCII.

On top of those, some controls read what the phone can do: the Shell section and the app library disappear entirely when an iPhone is in the selection, and Put selected devices onto TCP goes flat.

Activity — the icon at the top right, with a badge counting lines (99+ past ninety-nine). Every action reports there: the result of a bulk setting, shell output, a screen read, a rack key install, a phone dropping off the bus by name. It is this Mac's log of what it did to the phones in front of it, which is a different thing from Activity on the web, where jobs the server dispatched are recorded.

The sun/moon icon at the far right of the top bar. The choice is remembered on this Mac.

Not to drive phones. Plug a handset in, mirror it, tap on it, run a routine you wrote here — none of that asks a server for permission, and none of it stops when your connection does.

An account is needed for the cloud half: routines syncing to the dashboard, per-device profiles, automations the server runs, and Google Drive ingest. The first screen and the bell both say so rather than making you find out.

Four places, all the same flow: the worded button in the top bar (shown on every screen while signed out), the account icon at the foot of the rail, Settings → Account → Connect this computer, and the first-run screen.

The app asks for a code, shows it large, and opens your browser at my.noisey.app/link to approve it. It polls every 3 seconds and turns into Computer connected with your address when you approve. No password is ever typed into the desktop app — it never sees one.

The dialog has the fallback in it: go to my.noisey.app/link on any device — your phone will do — and type the code shown. There is also an Open the page again button. If the code has aged out the dialog says That code expired and offers Try again, which mints a fresh one instantly; codes last a few minutes on purpose.

The chip in the top bar. The address is blurred by default — click the eye to reveal it, because a shared screen or a screenshot should not hand out your email. Clicking the address opens your dashboard. The dot is green when the cloud is reachable and amber when this computer is signed in but cannot currently reach it. Settings → Account says the same thing in words.

The top-bar chip or the rail's account icon → Manage / sign out → Sign out. It asks first, and the dialog says what it is actually doing: signing out stops sync and new jobs for this computer, and the phones in front of it keep working. Activity logs This computer is signed out and the Connect button comes back.

Exactly what it says: Phones keep working; sync and new jobs wait until the connection is back. Nothing here is lost. Local device control never waits on a server, so mirroring, tapping and routines you run by hand carry on. The status is re-polled every 60 seconds, so the banner reflects now rather than whatever was true when you launched the app.

Two things have to be true before a tile can appear: USB debugging is on in the handset's developer options, and adb is on this Mac — the foot of the rail shows a green dot and the adb version when it is. Then plug in, accept Allow USB debugging on the phone, and press Rescan.

It worked when a tile appears with a green dot and the top bar counts read N ready. If the phone is listed but marked unauthorized, the trust prompt is the thing outstanding. An iPhone never arrives this way — it has its own setup, below.

Android phones are reached over adb, so until it is found none of them can be driven — the bell says exactly that, with an Open settings button, and iPhones are unaffected. Settings → Android Debug Bridge shows Status, Version and the full path the app is using, and the dot at the foot of the rail carries the same fact on every screen. Point NOISEY at a working adb and the dot goes green without a restart.

A banner above the grid reads N phones need attention and lists each serial with its state, so you fix named phones rather than hunting the grid for the odd one out.

On Android: unlock the handset and accept Allow USB debugging — tick Always allow from this computer so it survives replugging. On an iPhone: unlock and tap Trust This Computer; the pairing is per-Mac and there is no way around tapping it. It worked when the banner's count drops and the dot turns green.

Use rack key… on the N phones need attention banner. The rack vendor's “licence file” is an adb private key — installing it makes it this machine's adb identity, so every board provisioned with that key authorises without anyone tapping anything.

adb restarts, every board re-handshakes, and the app rescans at once and again 4 seconds later. Activity logs rack key installed and names the backup it saved under ~/.android/ if you already had a key. Android only: the button is hidden when every blocked handset is an iPhone, which has no equivalent.

Rescan — the circular-arrow icon in the top bar on the Phones section, disabled while a batch operation is running. Most of the time you will not need it: the list re-polls itself every 5 seconds. A phone that leaves the bus is named in Activity rather than just vanishing from the grid, so you find out which one went.

Toolbox → Network: set the subnet, a from/to range and the port, then Scan. Nothing needs to be selected — this is discovery. Settings → This machine shows your own address and subnet, and the subnet box is prefilled from it. The port box takes 5555, a list 5555,5037 or a range 5555-5560; ranges are capped at 64 ports so a typo cannot become millions of probes.

It worked when Activity reads found N adb endpoint(s), connected N. If hosts answer but none of them speak adb, the app tells you which of the two situations it is — the boards are up but not listening, so USB authorisation is still outstanding; or the rack is powered off or on another subnet.

Select the phones, then Toolbox → Network → Put selected devices onto TCP, which uses the first port in the port box. Android only — the button is disabled if any selected handset is an iPhone, and the hint explains why: adb-over-TCP is an Android thing, and an iPhone stays on USB for pairing and launching while its control channel already runs over your network.

The ●/○ eye button on the phone's row in the panel's Phones list. Only the tile goes away — a hidden phone stays selectable and stays usable, which is what you want for a board you are not watching but still want in a batch. The choice is remembered between launches.

Click the phone's name on its tile, type a new one, press Rename. Signed in, the rename goes through the server so the grid and the dashboard agree; offline it is kept as a local nickname on this Mac.

What the tile shows, highest first: a profile from the website, then the server's name for that device, then your local nickname, then the model, then the serial. If a profile is assigned the name is not clickable — that name is set on the website, and the tooltip says so.

Quickest: the density icon in the top bar, which cycles 110 → 150 → 220 px. Precisely: Settings → Device display → Small screen size (90–320 px), plus Main screen size (50–100%) for the focused view.

This is display size only. It changes nothing on the phone and does not reduce load — for that you want the encoder settings, two questions down.

• Green or amber dot — ready, or not ready.
• A small avatar — a profile is assigned to this handset.
• NNfps — the live mirror's frame rate.
• NN% — battery.
• ⤢ — open this phone on its own.
• The foot shows the serial; hover it for serial, resolution and OS version.

Two gestures, and they differ in a way worth knowing: double-clicking a tile selects only that phone and opens it, while the ⤢ button opens it and leaves your selection exactly as it was.

In the focused view the phone on screen always receives what you send it — a key press reaches it whether or not other phones are ticked. Whether the rest of the selection hears the same press is what Sync keyboard decides, and the hint under the key row tells you which way it is set.

Two ways, and the second is usually the one you want: the + on the rail's Groups header makes an empty group you then fill, while ticking phones and pressing New group from N selected in the panel names it and fills it in one gesture. The group appears in the rail with a count.

Select them, then Move to group… on the batch bar. The dropdown includes No group to take them out again, and it only appears once at least one group exists.

Click the group's name in the rail; All phones clears the filter. A group with nothing in it says so and offers a way out: Select phones in All phones, then use ‘Move to group’ on the batch bar.

The panel's Groups section — visible only when you have groups — has a tick per group. Unticking one takes its tiles off the grid. Hidden, not disconnected: those phones are still attached and still working.

No — groups are local to this computer and are not synced. What they are for beyond tidying the grid is scoping: a routine's Where and when → Run on can target A group, so “the morning shelf” becomes something you can point a schedule at.

The mirror icon in the top bar, which highlights when it is on — Settings → Behaviour → Mirror screens live instead of polling screenshots is the same switch. On, each phone gets a real video stream; off, the app polls a screenshot every 3 seconds. It worked when tiles carry an fps badge and the top bar reads N live.

The placeholder says which of three things it is:

• Waiting for a frame… — normal, and not a fault. A phone only encodes when its screen changes, so one sitting still sends nothing at all. Opening it in the focused view or expanding the tile forces a fresh frame.
• Mirror failed or Mirror ended, with a Retry button.
• The state word — unauthorized, offline — when the phone is not ready to be driven at all.

An iPhone's video arrives by a completely different route (WebDriverAgent, rather than the Android video stream) but the tile behaves the same.

Settings → Device display → Small screen resolution (240–1080 px) and Frame rate of small screen (1–60 fps). These are the phone's own encoder settings, not the size of the picture on your Mac — which is why the tile-size slider does not help, and why lowering these does. Changing either restarts every stream, and Activity says so rather than leaving you wondering why the grid blinked.

Click or drag straight on a tile, or on the big screen in the focused view. The phone you touched always gets the gesture; Sync decides whether the rest of your selection gets it too.

On a phone with no live mirror, the press and the release are collected and replayed as a tap or a swipe when you let go — so nothing moves on that handset until you release the button.

Sync in the top bar — also Sync mouse in the panel — makes one gesture drive every selected phone instead of only the one under the pointer. It is the answer to everything adb cannot do in bulk: put twenty handsets on the same settings screen, then tap through once.

Check they actually landed on the same screen before you start. Different firmware can land one level up, and a synced tap would then press something else entirely on that phone.

Sync keyboard, in the panel next to Sync mouse, governs how far keys and typed text travel while you have one phone open in the focused view. On, they also reach the other selected phones; off, only the phone on screen hears them — which is the setting you want when you are typing into one handset out of twenty.

The phone on screen gets the press either way. In the grid, where no single phone is open, keys and text go to every selected phone. The hint under the key row tells you which way the switch is set and how many other handsets are listening.

They sit on the batch bar in the grid, and in a row under the phone in the focused view. In the grid they go to every selected phone; in the focused view the phone on screen always gets them, plus the rest of the selection when Sync keyboard is on.

On Android, Back doubles as screen-on while a live mirror exists — the right behaviour for a shelf of sleeping boards. On an iPhone only keys with a genuine analogue translate: iOS has no Back, so pressing it returns an error rather than quietly doing nothing.

Open one phone, then press Read screen in the bar under it. The result goes to Activity — up to 40 lines, after which it says screen read — see Activity.

On Android that is uiautomator's accessibility tree; if the screen is mid-animation it retries up to 4 times and then admits it could not read it, rather than handing you half a screen. On an iPhone the tree comes from WebDriverAgent through the same reader Claw uses, so what you read is exactly what the model reads.

Type on devices in the panel: type, then press Type or Enter. It goes into whatever field is already focused on the handset — NOISEY does not choose the field, so tap into the box first (or let a routine do it). Needs a selection, and it follows Sync keyboard when you have a phone open in the focused view.

Tick Send as keystrokes under Type on devices. Left off, the text is pasted through the clipboard; ticked, it is pressed key by key — which is what a password field needs, because most of them refuse a paste.

Two conditions the box does not state. Keystroke mode is ASCII only and the app refuses anything else outright rather than sending mangled text, and it needs a live mirror session on that phone — without one it answers needs a live mirror session.

The clipboard route on its own — emoji and any script work, and it goes to every selected phone. It is capped by the device clipboard's maximum size; over that the app refuses and prints both byte counts rather than silently truncating what you wrote. With no live mirror it falls back to adb's own text input, which on Android is ASCII-only. An iPhone has no such ceiling: WebDriverAgent takes real UTF-8.

The phone had no live mirror, so the text went by adb's text input, which on Android cannot carry anything outside ASCII. The app says so instead of sending an approximation: needs a live mirror session — adb cannot type non-ASCII. Turn live mirroring on for that handset and send it again. iPhones are unaffected.

Bulk settings in the panel → Wi-Fi or Data → On / Off. It applies to the current selection and the section states the count: Applies to the N selected phone(s). Activity reports the result — wifi turned on on N phone(s). iPhones in the selection are skipped, and the panel says so: these controls write Android's settings store over adb.

Bulk settings → Lock all to portrait. Unlike the other controls in that section, with nothing selected this one falls back to every ready phone.

The write is verified rather than assumed — settings put exits 0 whether or not the value landed, so the app reads it back. Seven of nineteen boards were once found still unlocked after a console had reported success on all of them. Activity reads N phone(s) locked to portrait, and the grid rescans a second and a half later so the tile shapes update.

Not by command — you drive it. Joining a network needs root, and these boards cannot be rooted, so the app does not offer a button that would quietly fail.

What works: Bulk settings → Open on every selected device → Wi-Fi puts every selected handset on the Wi-Fi settings screen; turn Sync on and tap through once, and they all follow. The three screens with buttons are Language, Wi-Fi and Settings. Check they landed on the same screen before you start tapping — different firmware can land one level up, and a synced tap would then hit the wrong thing there.

Toolbox → Prepare for automation → Prepare selected, once per phone, before your first routine. It turns off Android's full-screen confirmation overlay — the one with no tappable button, which otherwise blocks automation on every full-screen app — and locks the handset to portrait. It worked when Activity reads N phone(s) ready for automation. Android only.

Select the phones, then Install app… on the batch bar and pick a .apk. For more than one file at a time, use Toolbox → Apps → App library.

Installs run in groups of 4 rather than all at once — twenty concurrent pushes down one shared USB hub is slower, not faster, which is what the pacing is for. It worked when Activity reads install → N phone(s) OK; failures come as a count with the first message attached. Android only: an iPhone needs a signed IPA and a provisioning profile per app, so the whole library section is hidden when one is selected.

Toolbox → Apps → App library → type a path or press Browse. Every .apk, .apkm and .xapk in the folder is listed with its package id, version and size — or unreadable — and split bundles are marked split. The folder is remembered for next time.

Toolbox → Apps → Quick install → Check N devices, then Install N missing apps. Each app goes only to the handsets that do not have it, and progress is reported per phone. Needs a selection and a library with something in it. It worked when you get either All N app(s) are on every selected device or a list reading missing on X of Y and then N installs succeeded.

Because two files in the folder declare the same package, and the library reads the package rather than trusting the file name: N package(s) appear more than once. The file name is not the app.

It is worth acting on. Three downloads named for Reddit, X and Bluesky once turned out to be byte-identical copies of the same app store — installing them would have put one store on twenty phones three times, and none of the three apps anywhere.

Toolbox → Apps → type the app's id → Launch. On Android that is a package name like com.example.app; on an iPhone it is a bundle id like com.apple.Preferences. The placeholder changes to match your selection, and a hint says which one it wants.

No — there is no uninstall control in the desktop app, on either platform. Remove it on the handset, or with adb yourself.

Toolbox → Shell → type the command → Run. It runs on every selected phone and the output goes to Activity — the first 3 phones, truncated to 120 characters each, because twenty full outputs is not a log anyone reads. The whole section disappears when an iPhone is in the selection: iOS exposes no shell, and the app does not pretend otherwise.

Select them, then Restart on the batch bar — styled as destructive, and it names the count before it goes. Mirror sessions are torn down first so the streams come back cleanly instead of reconnecting to a handset that is halfway through booting. Android only: an iPhone cannot be restarted from NOISEY.

There is no screenshot button. Screenshots exist inside the app only as the still preview it polls when live mirroring is off, and none of them is saved to your Mac. If you want what is on the screen as something you can act on, Read screen in the focused view gives you the elements rather than a picture — usually the thing you actually wanted.

Media → Choose folder… and pick a folder on this Mac. Videos in it become your library — drop a clip in and it is there, ready to send to any handset. The folder is remembered.

This is not the same Media as the website's. The web one is a cloud library that automations watch; this one is a folder on your own disk that you send to phones by hand or with auto-send.

Press Refresh in the bar at the top of Media. There is no watcher behind the library view, so a file that lands while you are looking at it does not appear on its own. The same bar carries the folder path and the video count, and the empty state names the folder it is watching — which is the fastest way to spot that the clip went somewhere else.

Select the handsets under Phones first, then press Send to N devices on the file's row in Media. Media has no phone picker of its own — with nothing selected the buttons are flat and the hint tells you to go and select some.

For a one-off file outside the library, Toolbox → Send a video → Choose a video… takes mp4, mov, m4v and webm. It worked when Activity says the file is now visible to pickers on N phones. Android only.

That is the app refusing to call a half-finished job a success. Sending a video does two things — copies the file to the handset, then makes Android index it — and a file that is on the phone but not indexed is invisible to every upload picker, which is the only reason you sent it.

Send it again. If it keeps failing on the same handset, that phone's media scanner is the thing to look at, not NOISEY.

Media → Auto-send → New, with a media folder chosen and handsets selected — the button is flat without both. The rule then reads as a sentence: when a video is added to that folder, send it to N devices, so many seconds apart.

It is created off. Press Turn on when you are ready and it checks every 15 seconds; Send now runs it immediately; the trash icon deletes it. Each rule remembers what it has already sent, so a file is never sent twice. The seconds apart are spacing for your own machine and bandwidth — one computer pushing to twenty handsets at once is a self-inflicted traffic jam, and that is all the spacing is for.

Auto-send moves files onto phones. It does not post anything. The vocabulary is worth keeping straight, because this feature used to be called Automations and the word then named two unrelated things:

• Routines — what a phone does.
• Automations — when a routine runs. Written on the website.
• Auto-send — how a video gets onto a handset. It lives under Media because that is what it is about.

Routines → New routine — from the empty state, or the button at the foot of the list — name it and press Create. A routine is deliberately one noun: whether it has been learned and whether it is scheduled are states it is in, not separate things to make. It syncs to your account, so a moment later the website offers it when you build an automation.

Routines → the routine → Instructions: one thing per numbered row, then Add an instruction for the next. They run in order, each on whatever screen the last one left behind — so “open TikTok”, then “press the plus”, not one row describing the whole post.

Reorder with the up/down chevrons and remove with the × on the row. Each row has Carry on even if this one fails for the steps that are allowed to miss — the cookie banner that is not always there.

Write {{something}} inside an instruction. A Needs entry appears the moment you type it, undefined and waiting to be told where its value comes from. That is the whole gesture — no form to fill in first, no library to populate, and a reference and its definition cannot drift apart because one makes the other.

Each need is Some text or A video, and takes one of three sources: Ask me each run, which prompts when it runs and therefore cannot run unattended; Always the same, a fixed value you type; or Newest unused file in a folder. It worked when the warning that nothing is defined for that placeholder disappears and Run comes back to life.

Give the need the kind A video and the source Newest unused file in a folder, then pick the folder. The file is pushed to the phones before any instruction runs, and what gets substituted into your wording is the filename. That is deliberate: the instruction ends up saying “pick clip-08-13.mp4 from the gallery” rather than “pick the newest video”, which works right up until something else on the handset is newer.

Routines → Guidance for Claw, free text — “captions are lowercase, one line, no hashtags”. It shapes what Claw decides, not what is sent to the phone.

A learned routine does not read it. Once the steps are compiled they are what runs, so guidance only matters while a routine is still thinking: changing it changes the next re-learn, not the next replay.

Routines → Where and when → Run on: All phones, A group, or Chosen phones — for which press Use the N selected.

The list is resolved when the routine runs, not when you save it, and chosen phones are matched by hardware idrather than serial. A routine scoped to serials would quietly drop a board whose address changed after a router reboot, and post to eighteen of nineteen with nothing in any log to say so.

Your choice, under Routines → Where and when → Afterwards: Go to the home screen (the default), Leave it where it ends, Close the app, or Lock the screen. It matters most when the next routine assumes it starts from home — a handset left inside an app is the usual reason a second run behaves differently from the first.

Run on N devices, at the top of the routine. Unsaved edits are committed first, so you run what you can read rather than what was last written.

It is flat when the routine has no instruction, nothing in scope, or a need with no source — the tooltip says which. A learned routine reports N ok, or X/N failed with the first failure quoted in full: the count tells you something broke, the message tells you what. A routine that has not been learned opens the Claw drawer instead, with one run per phone.

Save, in the routine's bar, with a live Saved / Unsaved changes indicator beside it. Switching to another routine commits the one you are leaving, so clicking away does not lose work — the button exists to tell you where you stand, not to be the only thing between you and losing an afternoon.

Routines → Where and when → Run it on a schedule, then Daily at a time, or Every N min. It worked when the row in the list carries a green dot and next HH:MM, and the meta line reads daily at 09:00 instead of not scheduled.

Two limits to know before you rely on it. The scheduler ticks inside the app, so routines only fire while NOISEY is running. And scheduled routines run one at a time — two firing at 09:00 across eighteen boards would fight over the same USB hub.

Run it once with Claw, then press Learn. That compiles what Claw worked out into steps that replay with no model behind them: the chip changes from Not learned to Learned, and the cost chip from thinks every run to free.

It learns from one phone's run, not all of them. The compiled steps find things by name rather than by coordinate and so are portable, and paying a model nineteen times for nineteen copies of the same route would defeat the point. The first handset to finish successfully is the one that teaches.

Read the note under the routine's bar — it says one of two things. Either Learned N step(s). Ends with a check, so a run that did not work says so, or, in bold, It has no way to prove it worked.

The second means the screen it finished on had nothing specific enough to check for, so a success there means only that no step errored. That is a different claim from “it posted”, and the app will not blur the two on your behalf.

Forget, next to Learn and flat unless the routine is learned, drops the compiled steps so the next run works it out afresh.

It also happens on its own when you edit the instructions, and Activity says so: the routine changed, so its learned steps were dropped, and it needs one run to learn again. A replay would otherwise keep walking the old route while the screen showed your new words. Only instruction edits do this — renaming or rescheduling does not.

Recent runs, under the routine — the last 8. Each row carries the time, N-failed/total ok, whether it replayed or ran through Claw, and scheduled if a timer fired it. Failed runs are highlighted and carry the first error, so the list answers “has this been working” without a trip to Activity.

The trash icon in the routine's bar. It goes immediately — there is no confirmation and no undo, so check you are looking at the one you meant before you press it.

The part of the desktop app that drives phones from plain English. Press Claw in the top bar, say what the handsets should do, and press Run on N devices. You need phones selected and an engine configured in Settings → Claw.

Every selected phone gets its own independent run — one that goes off script is reasoned about on its own rather than blindly copying another — and each shows as a card with a status chip and its steps.

Because no engine is configured yet. Claw drives phones with a language model and NOISEY does not resell one: you bring either an OpenRouter key or your own Claude subscription, in Settings → Claw. Keys and tokens are kept in the macOS keychain, never in a file. Nothing about the rest of the app needs this — mirroring, typing and learned routines all run without a model.

Settings → Claw → Engine → OpenRouter — pay per token, paste your sk-or-… key, press Save key. It worked when the key row's dot turns green and reads In the keychain.

For the model, take the benchmarked default, the escalation model (most reliable in the benchmark, ~6× cost), or any OpenRouter model id you type. An explicit choice runs exactly as chosen — a failed run only retries on the stronger model when the benchmarked default is the one selected.

Settings → Claw → Engine → Your Claude subscription opens a three-step checklist: Claude on this Mac (with an Install Claude button if it is missing), Your Claude subscription (the next question), and Model — Sonnet (fast, on every plan), Opus (most capable, needs Max) or Haiku (cheapest, simple tasks) — then Test it. Already signed in to Claude Code on this Mac? The card says so and offers nothing to press.

Two limits. Runs use your own Claude plan and its rate limits, and Approve every step is not available on this engine, because a headless run cannot stop to ask. If ANTHROPIC_API_KEY is set on this Mac the card warns you: runs then bill your API account by usage rather than your subscription.

Because claude setup-token opens a browser and then waits for the authorisation code to be pasted back on standard input, and an app window has no standard input to paste into. So Get a Claude CLI token opens a terminal instead: follow it through, copy the sk-ant-… token it prints, paste it into the field and press Save.

Improve, under the Claw box, rewrites what you typed as numbered steps a phone can follow — “open X, go to a profile, follow ten of their followers” is one sentence to a person and about fourteen actions to a handset.

It replaces the text in place so you can read and edit it before anything happens, and the hint says as much: nothing runs until you press Claw. It may not add steps you did not ask for. The prompt behind it is yours to edit in Settings → Claw → Improving a request, with Save prompt and Reset to default — leave it empty and you get the shipped one, shown greyed in the box as a placeholder.

Tick Approve every step before it happens in the Claw drawer before you run. Each step then waits for you. OpenRouter engine only — the Claude subscription engine runs headless and cannot pause to ask, and the checkbox says so rather than silently ignoring you.

Settings → Claw → Devices at once: All of them, or a number from 2 to 20. Anything over the limit waits its turn and shows as queued, and the limit is shared by every routine running — two at once still add up to this number.

The hint states the real cost and changes with the engine. On OpenRouter nothing runs on your Mac, so it is only about how hard you hit the phones. On the Claude engine it is memory: that engine runs one process per handset, at roughly 500 MB each.

The run card shows the question with a box under it — type the answer and press Send. The chip on that card reads asking while it waits, so a run that has stopped is never a mystery. Only that phone's run is waiting; the others carry on.

Stop on the run card, shown while a run is running, asking or queued.

The run card lists the last 6 steps as the tool it used and the reason it chose it, with failures highlighted. Above them a strip carries one dot per instruction — done, now, failed — and a count like 3/5. It is a strip rather than a sentence because nineteen of these have to fit on one screen. Clear finished on the Runs header tidies the drawer when you are done.

The Claw drawer's header carries a running dollar total to four decimal places, priced against the default model's list price — money, not tokens. It is your key and your account either way: on OpenRouter you are billed per token by them, and on the Claude engine it comes out of your own subscription's limits.

On a finished run, press Save as routine and name it. It arrives already learned, because it just succeeded on that handset, and scoped to that handset rather than all of them. Widen it under Routines → Where and when once you have watched it do the right thing somewhere else.

By design. Both are right-hand inspectors about 340 px wide, and having both open on a laptop leaves too little grid to be worth looking at. Opening one closes the other.

Two ways in, and the first is the comfortable one:

1. Open one phone in the focused view and press Record in the top bar. Do the thing on the screen in front of you, then press it again — it now reads Stop · N with the step count.
2. Or Recordings → Record on the selected device in the panel.

Needs exactly one phone selected; otherwise the rail says Select exactly one device to record. Name it, press Save routine, and it appears under Routines like any other. Cancelling throws it away.

For the things adb cannot do in bulk — changing the system language, joining a Wi-Fi network, anything that exists only as a screen in Settings. Record it once on one handset and replay it on twenty. For anything with names on screen to aim at, written instructions travel better between phones, for the reason two questions down.

No. Anything you type during a recording becomes an Ask me each run need with no stored value — the characters are dropped when the recording is compiled and are never written into the routine, so a recording can include a password without storing one.

That matters more than it looks: a routine body syncs to your account in the clear. Recorded counts — how many times you repeated something — are kept as Always the same and stay editable under Routines, so a scheduled run does not stop to ask a question nobody is there to answer.

Because it replays exact coordinates, and a coordinate carries no name and no checkpoint. A tap at a position cannot fail — every handset would report success while pressing whatever happened to sit at those pixels.

So it is scoped to the phone you recorded on, and the app says so when you save it. Widen it under Routines → Where and when once you have watched it do the right thing on a second handset. It is a deliberate edit, never a default.

Yes — timings are captured and replayed as recorded, because screens need time to settle and replaying instantly just races the UI. Nothing is randomised: the delays are the ones you actually took, kept for reliability, and they are not there to make anything look like anything.

Failures only. It holds the recordings that could not be turned into routines and are kept as local replays instead — they stay on this Mac and never sync. Each has Play, which sends it to every selected phone, and × to delete.

A recording that compiled cleanly is a routine and appears under Routines, not here. An empty Recordings list is the good outcome.

Xcode and an Apple Developer account, and there is no route around them. Apple permits one app to drive another only under UI testing, so NOISEY builds and signs WebDriverAgent on your Mac for your specific handset — there is no download-and-run version, and there cannot be.

That makes iPhone support a tool for the person who owns the phone, not something you can hand to a customer. Android asks for none of it: a toggle in developer options and a cable.

Settings → the iPhone card → Set up iPhone. One button: it does every step a machine is allowed to do, then tells you what is left for you. It is idempotent and safe to press repeatedly — that is the intended way to use it — and progress lines stream into the card while it runs, because the downloads inside take minutes. It worked when the card reads Ready — an iPhone tile can be opened and a tile appears.

Seven checks, each with its own fix text. Three run themselves; four are physical or need your Apple ID, which is why it is a checklist and not a progress bar:

• Xcode installed — yours: install it, then open it once to accept the licence.
• iOS platform support — automatic. Xcode 26 ships without it and can fetch it headlessly.
• Device tools — automatic.
• Apple Developer team — yours: Xcode → Settings → Accounts, sign in. NOISEY finds the team afterwards.
• WebDriverAgent source — automatic, cloned on demand. Never vendored, because it has to be signed with your own team.
• iPhone connected — yours: plug in, unlock, tap Trust. A charge-only cable looks identical to a data one and the Mac simply never sees the phone.
• Developer Mode — yours: Settings → Privacy & Security → Developer Mode, then restart the phone and unlock it.

Check again on the same card re-runs the lot without redoing anything.

The bell carries the reason: No iPhone on this Mac or iPhone not ready yet, with the blocking check's fix text as the body and a Check again button. In practice it is almost always one of the three physical steps — the cable, Trust, or Developer Mode. The notice only ever appears for people who have been through the setup, so nobody driving Android boards is nagged about a phone they do not own.

A fair amount, and the app hides the control rather than failing at the handset wherever it can:

• No shell. The Toolbox's Shell section disappears when an iPhone is selected.
• No installing from a file. That needs a signed IPA and a provisioning profile per app, so the app library is hidden.
• No Android settings. Bulk settings skip iPhones — change those in the Settings app, or point Claw at them.
• No adb over TCP, and no restarting, and no sending a video to the gallery.
• No Back key. iOS has none, so pressing Back returns an error rather than quietly doing nothing.
• Launch takes a bundle id, not a package name.

What does work is most of the point: mirroring, tapping, swiping, typing — real UTF-8, with none of Android's ASCII ceiling — reading the screen, routines and Claw.

Four tiles across the top, each a link: Phones connected (live out of registered), Automations on (enabled out of total), Media waiting (files held right now) and Posted this week.

Under them, in order: Needs a look when something is wrong, the three-step setup checklist until your account is set up, a seven-day chart of posts, and Get the Mac app. Nothing here controls a phone — the dashboard says what is happening and sends you to the page that can change it.

The first number counts handsets a connected computer can see right now; the second counts what is registered to the account. Zero means no Mac of yours is connected — or one is, and it cannot see the phones (cable, or an unaccepted trust prompt). The second number never falls on its own: a phone stays registered while your Mac is off, which is exactly what lets an automation you build today dispatch to it next week.

Three things, aggregated, and it appears only when there is something in it: a source whose last Google check errored, the count of failed jobs, and the count of scheduled runs recorded as missed (worded “was the Mac open?”). Each line links to the page that explains it. There is no green all-clear version — an absent card is the good outcome.

1. Connect your Mac — the pairing code from the desktop app.
2. Plug in a phone — this opens the help centre, in the same tab, so use your browser's back button to return to a half-finished setup.
3. Create an automation.

The checklist disappears once all three are true — a computer connected, at least one phone registered, at least one automation — and does not come back.

The last seven days in your own timezone, oldest first: green for posted anchored to the baseline, red for failed stacked on top, the total above each bar and the exact split on hover. Only finished jobs are counted — queued, running and missed do not appear — so a day when your Mac was shut reads as an empty bar rather than as a row of failures.

Everything except touching a phone.

• Works with the Mac shut: the whole dashboard, writing and editing routines, automations and flows, the webhook receiving files, Drive sources, flows running on our servers, the calendar, the store and the community.
• Waits for the Mac: every job dispatch, Try it on a phone, Pick it off the phone, and a flow’s Run a routine step.

Jobs queued in the meantime are not lost; they dispatch the moment the desktop app connects, unless their start window has already closed.

The dashboard reads from api.noisey.app across origins, with your session cookie attached. A browser blocking third-party cookies makes every one of those reads look signed out: pages render empty, sign-in loops back to sign-in, and my.noisey.app can sit on “Loading…” forever. The give-away is that nothing is in error — it is all just blank. Allow cookies for noisey.app, or try another browser to confirm it.

Yes. The left rail slides off-canvas behind a hamburger at the top left on narrow screens and closes as soon as you navigate; the routine and flow editors collapse from three columns to one below 1100px; the calendar steps 7 → 4 → 2 → 1 columns. Lists, activity and the community read well on a phone. Drawing a graph on one is possible and not pleasant.

The book icon at the foot of the left rail, between Settings and Sign out. It opens this help centre in a new tab, so you keep whatever you were half-way through.

Three kinds share one list.

• Drawn — a graph authored on the canvas. Open takes you back to it.
• Written in sentences — plain instructions a Mac teaches itself the first time it runs them.
• On a Mac — taught in the desktop app and mirrored here so an automation can choose it. It says learned or not learned yet.

The kinds overlap: a routine taught on a Mac now carries its graph up with it, so it can be machine-authored and drawn at the same time.

Yes — press Open on its row. A routine taught in the desktop app arrives with its graph, so it lands on the canvas like any other: the same boxes, the same wires, the same inspector. Edit it, save, and the new version goes back down to every Mac on your account.

A row with no Open is one written as sentences rather than drawn. Those are still changed in the desktop app on the machine that owns them.

Whichever side saved last wins, and the page says so above the canvas. Your edit goes out as a newer version and each Mac replaces its own copy rather than merging the two — a half-merged routine that runs differently on one handset is worse than a lost edit. Edit in one place at a time.

Five groups in the Add a step palette:

• Navigation — press back; press home; open an app by package name; open a settings page.
• Interaction — tap; tap if it is there, for the dialog that only sometimes appears; type text; scroll until found, with a give-up count; tap a coordinate, labelled last resort because coordinates differ between handsets.
• Wait & check — wait for something, with a timeout; wait a fixed number of milliseconds; check it worked; stop if this appears; check the phone is fit, with a minimum battery and a maximum temperature.
• Decisions — if it is on screen; if a value is; if a count is under; stop, with a message.
• Values — remember a value, readable later as {{name}}; count up.

Check it worked is the proof: a routine without one cannot say it succeeded, only that it finished.

Halting loudly instead of tapping through something the routine does not understand — a rate-limit notice, a consent gate, an account warning. You name what to look for and the message to record, and the job stops with that message on its row in Activity. It is a stop sign, not a way around anything: the correct response to a platform telling you to slow down is to stop.

The box wearing the Start pill. The first step you drop on an empty canvas becomes it automatically; to move it, select another box and press Start here in the inspector. A routine whose start is not one of its own boxes is refused at save.

A decision has two dots under it instead of one: green yes on the left, red no on the right. Drag from the one you mean to the top of the next box. Ordinary steps have a single outgoing dot; Stop has none. To remove a wire, click it and press delete — both boxes are updated, so nothing is left pointing at a connection that no longer exists.

Click the box. The inspector on the right renders exactly the fields that step carries and nothing else. Delete in the inspector removes it and clears any wires pointing at it, so saving does not then fail on wiring you never drew.

Save routine, top right. The name comes from the field above the canvas; blank saves as “Untitled routine”. Success reads “Saved — version N. Your Mac picks it up on its next connect.” The first save also puts an id in the address bar, so a refresh keeps the routine rather than handing you a blank canvas.

A box nothing connects to is nearly always a forgotten wire — draw it, or delete the box. Saving checks the whole graph and names one problem at a time:

• at least one box, and not more than the cap;
• every box with an id, and no two the same;
• every step one this build can actually run;
• every wire pointing at a box that exists;
• the start being one of the boxes, and every box reachable from it.

All of it is refused here rather than at three in the morning on a phone.

Write {{name}} inside a type-text step. The value comes from a Remember a value step earlier in the graph, or from an input the automation supplies. Do not leave a routine asking a human for the value: one that does is hidden from automation and schedule pickers, because nobody is there at 9am to answer it.

Two reasons the button refuses:

• No phone is connected. A trial is a real run on a real handset, so the desktop app has to be open with the phone attached.
• You already have three trials going: “you already have trial runs going — wait for one to finish”.

A trial saves the routine first and runs the saved version, so what you watch is what is on your screen. The panel keeps the last 12 steps and a trial expires after 10 minutes.

Delete on its row, confirmed by name: “Delete <name>? This cannot be undone.” It is offered only on routines authored here. One that lives on a Mac is deleted in the desktop app instead — that machine holds the copy, and deleting it from the web would only wait for the next sync to put it back.

The canvas draws graphs, and that routine is a list of plain instructions — there is nothing to lay out. Change it in the desktop app, on the Mac that owns it; there is no editor for a written routine on the web yet. If you would rather have it drawn, draw it: Routines → Draw a routine gives you the same task as boxes, which is also the only shape the store will publish.

It names the missing answer rather than greying the button out. The messages, in the order you hit them:

• “Pick the folder that triggers it.” — or, on a schedule, “Pick the folder it posts from.”
• “Pick the routine to run — or write one.”
• “Pick the phone — or phones — it runs on.”
• “Picking several means at least two phones — for one, choose it directly.”

A schedule additionally needs at least one time. Nothing is created until every answer is in: an automation missing its target is one that silently never runs.

Press Edit on the automation’s card. The same form you built it with opens with every field filled in, and Save changes writes them back.

You can change its name, the folder it watches, the routine it runs, the phone or group it runs on, the stagger, and — on a scheduled automation — the times, days, timezone and window.

Whether it is paused is deliberately not part of the form: Pause and Resume are their own button on the card, so saving an edit never quietly restarts something you had stopped. Jobs that already ran are unaffected either way.

For a schedule: the start window (“starts by +30m or it’s marked missed”) and then either the next run as a date and time, “no upcoming runs”, or “paused”. That next run is computed by the server, not your browser, so it is the same instant the job will use. For a group firing on arrival: the seconds between phones and the date it was made. via <machine> appears when the routine belongs to one Mac.

Because 09:00 has to keep meaning 09:00 through a clock change. An offset like UTC+1 is correct for about half the year; a named zone carries its own rules and shifts with them. Your own zone leads the list, marked — yours, and a schedule set in someone else's zone appears on the calendar at the hour it will actually run for you.

You have routines, but every one of them asks a question at run time, and a scheduled run has nobody to answer it. Give that input a fixed value in the desktop app — or take it from the incoming file — and the routine becomes selectable. With no routines at all the page says Start with a routine instead, and offers New automation and Connect a computer.

Three places, all producing the same kind of run:

• Automations → New automation → On a schedule — the general one: a routine, a folder, times, days, a zone, and any phone or group.
• Phones → Schedule on a handset's row — this phone, at this time, whoever it is posting as.
• Profiles → a profile → Posting schedule — follows the person, and runs on whichever handset carries them.

Choose by what you want to survive a change: a profile's schedule keeps working when the client moves to a different phone, a phone's keeps working when the client changes.

1. Phones → Schedule on that handset's row, then Schedule something.
2. Run — the routine. Posting from — the folder it draws files from.
3. Times, day toggles, the timezone, and how late it may start.
4. Schedule it.

It appears in that phone's list with its next run, and on the calendar, named “<Routine> on <Phone>”. It needs at least one routine and one folder to already exist; the form says which is missing.

A schedule needs somewhere to run, so assign the profile to a handset first: Phones → the Posts as dropdown on the row → pick the client. The section on the profile stops refusing immediately. Until then it says “<name> isn’t on a phone yet, so a schedule would have nothing to run on.”

Every row in a posting schedule carries Pause / Resume and Remove, and shows its next run, “no upcoming runs” or “paused”. Pausing one time leaves the others armed. Like an automation, a time cannot be edited once added — remove it and add the one you meant.

Flows → New flow. Name it, pick what starts it from the chips under Starts when, add steps from the palette, drag from the dot under one box to the top of the next, then Save flow. The wiring rules are the routine canvas's rules: every step reachable from the start, every wire pointing at a step that exists.

Five, and exactly one per flow:

• By hand — only when you press Run now. Good while you are building it.
• On a schedule — times, days, a named timezone.
• When a file arrives — anything landing through your webhook, optionally narrowed to one folder.
• When something happens to a phone — a job finished, failed or was missed; a routine ran; a phone connected or dropped off; a computer connected or disconnected.
• When a phone gets a notification — optionally one platform: LinkedIn, TikTok, Instagram, X, Facebook or YouTube. The editor warns on this chip that a flow saved against it does not fire yet.

The trigger is deliberately not a box on the canvas: every flow has exactly one, and a box people can delete or leave unwired is a flow that can never fire.

Two groups.

• Thinking — Ask a model (a prompt, an optional system prompt, a name to store the answer under, and a token ceiling); If a value is; Remember a value.
• Doing — Run a routine, which takes a routine and one phone and is where a flow reaches the real world; Call a URL; Write to the timeline; Stop, with a message and a tick for whether it counts as a failure.

{{name}}, where the name is whatever you typed in the output field on Ask a model or Call a URL, or the name on Remember a value. Write it into any later step's text — a prompt, a URL, a body, a timeline note. It is the same {{name}} notation a routine uses, so there is nothing new to learn moving between the two canvases.

Run now in the header. It saves first, runs the saved version, then lists every step with its detail and how long it took, colouring the boxes green where they worked and red where they stopped. Boxes left grey were never reached — which is usually the answer to “why did it not do that bit?”: the flow took the other branch.

On NOISEY's servers, which is the point of them: the trigger fires, the model thinks and the URL is called with your computer shut. Anything a flow does to a phone still waits for your Mac — a Run a routine step queues a job like any other and dispatches when the desktop app connects, because only your computer can reach your handsets.

A Run a routine step offers only routines authored on the web, so one taught on a Mac is absent and nothing on the page says why. Draw the routine at Routines and it appears in the list. Automations do not share this restriction — they will happily point at a machine's routine.

Three refusals, all decided on the server: “that is not a URL a flow can call”; “a flow can only call http or https”; and “a flow cannot call an address inside the network” — loopback, private ranges and cloud metadata addresses are blocked outright. The request comes from our servers rather than your browser, so an unblocked one would let any account reach things that are not theirs.

Four causes, each with its own message:

• No key is stored. Flows run on our servers and cannot reach the keychain on your Mac — add one under Settings → AI for flows.
• The month's allowance is gone: “that is this month’s N AI actions used up”. The free plan’s allowance is 0, so an Ask a model step fails the first time it runs on a free account.
• “the AI provider rejected the key — check it under Settings”.
• “the stored AI key can no longer be read — save it again under Settings”.

Pause / Turn on on the row, and delete with a confirm. A paused flow keeps its trigger and its graph and simply does not fire; the row says “· paused” after the name. The list also carries the trigger, the number of steps, how many times it has run, and when it was last changed.

Free: 3. Paid: unlimited. Over it, creating one is refused with “that is your 3 flows used — the paid plan lifts the limit”. The cap counts flows you have, not flows running, so a paused one you have finished with is worth deleting rather than leaving switched off.

Filename, size, when it landed, when it expires (“expires in 19h”, “expires in 3d”) and a download link. A folder holding anything expiring inside 48 hours repeats that warning at the top, because the retention clock starts when the file is uploaded and not when it is posted — a video sitting unposted is spending its life.

You cannot — there is no delete control in either app, and no route behind one. Files leave by expiring: 24 hours from upload on the free plan, 90 days on paid. If something has to go sooner, write to support@noisey.app.

Two consequences worth knowing. The stored-file cap counts what you are holding, so posting and letting files expire is what keeps you under it. And identical bytes are deduped rather than re-ingested, so an accidental repeat costs you nothing — but a corrected copy is genuinely new and lands beside the original rather than replacing it.

Then nothing has been POSTed to it. A file is routed by the request, never by the folder page: add ?folder=<the name> to your webhook URL, or point a Drive source at it. The empty folder prints the exact query string to use. Files sent with no folder at all are not lost — they are listed under No folder. With no folders at all, the page offers Make your first folder.

Tokens minted before the account-wide URL existed. Each was bound to a single folder, and they are listed under that folder and keep working until you revoke them. Some are older still and show “made before copying existed — recreate it once”, with no copy button. The account-wide URL replaced them because a pipeline feeding three folders meant juggling three secrets.

Sources in the left rail, at my.noisey.app/sources. It lists every Drive folder feeding NOISEY as “into <folder> · N files seen · checked <time>”. Add one with Watch a folder.

Yes. The top level of the picker lists your drives, and shared ones carry a people icon rather than a folder icon. Browse into it and pick the folder as usual — you choose it by looking at it rather than by pasting an id, which is what stops a source watching the wrong folder under a label that looks right.

Check now on the source. Left alone it is checked every few minutes on our servers, so a Drive folder ingests with your computer off — the posting still waits for your Mac. Check now is for when you have just dropped a file in and want to watch it land.

The × on the source card, which takes effect at once and asks for no confirmation. Files already ingested stay in their NOISEY folder until they expire, and nothing at all changes in Drive — NOISEY reads the folder you picked and never writes to your Drive.

The Posts as dropdown on the phone's row at Phones. Pick the profile; it takes effect immediately, and Nobody yet removes it. One profile per phone, deliberately — a handset posting as two clients makes “which account did this job post to?” unanswerable, and that answer has to survive into Activity and the calendar. The desktop app can set the same thing; both write the same field.

Opens the profile that phone posts as. If it has none, it takes you to Profiles, where you can create one — which is a shorter path than hunting for the client by name and coming back.

You cannot, from either app — there is no delete control and no route behind one. A handset stays registered after you unplug it, which is what lets an automation you build today dispatch to it next week. It also means a phone you have retired keeps counting against the plan cap (2 free, 10 paid), so write to support@noisey.app to have one taken off.

Because the page is read-only on purpose, and our servers never touch a handset. Everything you do to a phone — mirroring, tapping, installing, screenshots, batch operations — is in the desktop app, which is the only thing physically attached to it. A reboot button here would file a request and hope.

There is no group manager on the web. A group is made as a side effect of building an automation — choose Several phones…, tick the handsets, name it — and from then on it is offered as a target anywhere a phone can be picked. The desktop app has a proper Groups list; the web only has this route in.

Profiles → New profile. A name is the only thing required; a handle and a main platform are optional and can wait. You land on the profile itself, where the brief, the accounts and the posting schedule are edited. Creating one assigns it to nothing — putting it on a handset is the Posts as dropdown on the Phones page.

Phones → the Posts as dropdown on the handset's row → pick the client. That is the whole step, and it takes effect immediately — the phone stops being called SM-G986U1 everywhere it appears, and Activity starts answering “what happened on Jane’s phone today?”. A profile with no phone can still be written and briefed; it just cannot be scheduled.

Open the profile → Accounts → pick the platform, type the @handle, optionally paste a link to the profile → Add account. One client usually has several: the same person on LinkedIn and TikTok is one profile with two accounts, not two profiles. This is the join a notification resolves through — a reply to @jane on LinkedIn becomes this client, then their phone, then a routine.

No, and there is deliberately no button that would: you write this — NOISEY never invents a voice for an account. There is also no control for varying a voice across handsets, and there will not be. A brief describes a real person who holds a real account; a knob for making accounts sound unrelated to each other only makes sense if they are not.

Open the profile and use Picture → Add a picture. Anything square looks best; a wider or taller image is cropped from the centre.

It is shrunk to 128 pixels on your machine before it is uploaded, so a large photo is not sent and then refused. The picture then appears wherever that profile does — the profiles list, the phone it posts from, and the calendar.

Your own account picture is a separate thing, set under Settings → You.

A read-only strip of platform icons with the profile's main platform highlighted. It reports what the profile is set to; it is not where accounts are added. That is Accounts, further up the page.

Everything booked to run in a week: scheduled automations in green, scheduled flows in amber, faded when paused. Automations that fire when a file arrives are never here — they have no time, so there is nothing to draw, and an account that works perfectly can have an empty calendar. Occurrences are computed by the server, so the calendar and the job agree on what “09:00 in Europe/London” means.

← Previous, This week and Next → above the grid, with the date range and “shown in <your timezone>” beside them. This week is greyed out when you are already on it.

Yours. A schedule set in another zone appears at the hour it will actually run where you are — 09:00 New York sits at 14:00 in London — and the entry's own zone is in the hover tooltip. This is why the schedule form insists on a named zone rather than an offset: the conversion has to survive a clock change.

The time, the automation or flow name, and the client — the profile name, falling back to the phone name when the phone posts as nobody. Which handset does the work is the tooltip's job: name · as <profile> · on <phone> · timezone. Include paused, on by default, keeps paused items visible and faded.

Then nothing you have is on a clock. Arrival-triggered automations never appear here, so check Automations before assuming something is broken. The empty state offers the two ways to fill it: Schedule a phone and New automation.

Activity, which has two tabs. Timeline interleaves jobs, connections and failures per phone and per client — the shape of the question people actually ask (“what happened on Jane’s phone today?”). Jobs is the narrow view: just the work, with its errors. Timeline loads 150 events, Jobs 100.

The All phones select on the Timeline tab narrows it to one handset. Only trouble leaves warnings and errors and hides everything routine. When that toggle finds nothing it says so plainly: “Nothing has gone wrong. No warnings or errors in this window. That is the good outcome.”

• queued — the server has the job and is waiting for one of your computers to be connected.
• dispatched / running — it is with your Mac, or on the phone now.
• success / failed — finished. A failure prints its reason on the row, in red.
• missed (amber) — the start window closed before your Mac was there. Nothing broke and nothing posted.
• cancelled — stopped before it ran.

A row also shows the attempt count when there was more than one.

Free: 7 days. Paid: 90. Events fall out of the window rather than hiding behind a filter, and there is no export, so anything you need for a monthly report has to be read while the window still holds it.

Nothing has run yet: “Connect NOISEY on your Mac and the timeline fills as your phones work.” If you know jobs have run, the page is more likely signed out than empty — see the blank-page answer in the dashboard section.

In the editor's run panel for the run you just started, and nowhere else — there is no flow run history page yet. To leave a permanent trace, give the flow a Write to the timeline step: that lands in Activity with everything else, and is worth adding at the point a flow makes a decision you will later want to explain.

Each row carries the kind, the author, how many installs it has, its rating and how many people rated it (or “unrated”), which version of NOISEY it was built against, its age, and the author's description. The Everything / Routines / Flows chips filter the list. That “built against” line is the closest thing to a freshness date — read it before an old routine surprises you.

The five glyphs on the row, titled one to five stars. Rating again replaces your previous rating, and the row then shows the new average. It does not show what you gave it, so note your own verdict somewhere if you want to remember it.

Free: 3 live listings. Paid: unlimited. Only a drawn routine can be published — one written in sentences is a set of instructions for your own phones and is not portable, so the picker says “No routines to publish yet” when nothing qualifies. Flows can be published as they are.

Filter the store by Mine to see only what you published, then press Unpublish on the listing and confirm.

It disappears from the store immediately. Copies people already installed are theirs and are untouched — withdrawing a listing stops new installs, it does not reach into anyone’s account and remove a routine they are using.

Six: Announcements (staff start the threads, anyone replies), General, Automations & routines, Phones & hardware, Feature requests — one request per thread, so likes mean something — and Show & tell. The chips along the top filter to one topic; All returns to everything.

1. Community → Start a thread.
2. Pick the topic.
3. A Title, up to 120 characters, and the post itself, up to 10,000.
4. Post thread.

You land on the new thread. If your account has no display name yet, the composer asks for one there and then — posting is the moment it is needed, so it is not an errand in Settings first.

The Reply box at the foot of a thread, up to 5,000 characters, then Post reply. The heart on any thread or reply likes it and fills in; pressing it again unlikes. Both sit behind flood cooldowns — one new thread every 2 minutes, one reply every 10 seconds — which exist to stop a script, not to pace you.

Staff pinned the thread to the top of the list, or closed it to new replies. A locked thread replaces its reply box with “This thread is locked — staff closed it to new replies.” Both are staff-only; you can still read a locked thread, and still like it.

Load older threads at the foot of the list. It works from a cursor rather than page numbers, so threads posted while you are reading do not shuffle what you have already seen onto another page.

Settings → AI for flows. Pick the provider — OpenRouter or Anthropic — paste the key, optionally name a model, and Save key. Success reads “AI key saved. Flows can think while your Mac is asleep.” The card then reports which provider is stored, the model in use, and how many AI actions you have spent this month.

No — not even to you. The card can say that a key exists, replace it, or delete it, and that is the whole set. A field that can display a secret is a field that can leak one; keep your own copy with your provider.

Delete key, confirmed with “Delete the stored key? Flows that ask a model will stop until you add another.” Your Mac's own key is untouched — that one lives in the macOS keychain and is a separate thing. Deleting this one only affects flows, which run on our servers and cannot reach a keychain on a closed laptop.

The deployment is missing the encryption key it would protect yours with, so it refuses rather than storing a secret in the clear: “this server cannot store a key securely — use the key on your Mac instead.” Routines run by the desktop app are unaffected; only a flow's Ask a model step is. Tell us at support@noisey.app — that one is ours to fix.

No. Settings keeps two separate lists and they do not overlap. Sessions → Sign out everywhere else ends other browser sessions. Your computers → Sign it out unlinks a Mac. For a machine you no longer have, do both. Signing a computer out stops it syncing and receiving jobs — it keeps driving the phones physically in front of it, which is the point of the desktop app working offline.

Nowhere in the dashboard yet: no plan indicator, no usage meter, no upgrade button, and paying is not wired up. Today the only place your plan announces itself is the message when you hit a limit (“automations limit reached (1/1)”). Assume you are on the free plan unless you have arranged otherwise with us — the numbers for each plan are in this help centre.

There are none. NOISEY sends only transactional email — confirming an address, resetting a password, confirming a change of address — so there is nothing to opt out of, no digest, and no alerting to configure. The newsletter on noisey.ai is separate and opt-in.

The sign-out icon at the foot of the left rail, third of three after Settings and the docs book. It signs out this browser only — other browsers and any linked computers keep their own sessions until you end them from Settings.