What would your prompt launcher look like if you could simply tell it what you wanted? That is the question Promtly is built to hand to its user.
Promtly puts the sentences you keep retyping (the house style, the review checklist, "don't change anything I didn't ask about") one keystroke away, in whatever window you are working in. Setting it up is one paste. On promtly.dev/bridge, the Ask your agent tab has a Copy the setup prompt button. Paste that into Claude Code, Codex, Cursor or any coding agent with a terminal, and it downloads Promtly, starts it, sets it to start when you sign in, and tells you the two keyboard chords it chose.
Then you make it yours in the same conversation. Every colour, corner and
spacing value is a token in a local theme.css, and a local custom.js runs
inside the page, so "make it darker", "add my code-review checklist as pads" or
"give me a button that does this" is an edit your agent can make. The launcher
picks it up within about a second. Promtly even writes a reference file,
PROMTLY-CUSTOMIZE.md, listing every token and what it paints, so the agent's
first attempt lands. Prompts, layout, behaviour: whatever you can describe, you
can ask Claude or Codex to build into your own copy.
Sets of prompts already travel as packs that install from a link. The next step is a marketplace where people share whole Promtly setups with each other, peer to peer. That is planned, not built.
So the real question is what Promtly turns into for you. And as of today, the part of it that runs on your computer is open source, which is exactly what makes it safe to hand to an agent and say "change this".
Most software you install asks for trust in the abstract. A small class of it asks for something specific: permission to press keys into windows that belong to other programs, and to read whatever is on your clipboard. Launchers, text expanders, dictation tools and the new wave of AI assistants that paste into your editor all sit in that class, and most of them are closed.
Promtly belongs to that class. It is a prompt launcher: you press one chord over whatever you are working in, pick a saved prompt, and it lands in that window's text box. Disclosure before anything else: Promtly is made by the person who runs Hugin. Today its local half went public on GitHub, under the MIT licence, and the reasoning behind which half is worth setting out, because it applies to every tool in that class.
Try it in a minute
- Open promtly.dev and save the prompts you keep retyping as pads.
- On promtly.dev/bridge, copy the setup prompt
into Claude Code or Codex. Or download
promtly-bridge.cmdand double-click it, or runnode promtly-bridge.mjsyourself. - In any window, press the chord, pick a pad, and it lands where your cursor was.
- Ask your agent to change whatever you want changed.
The board works in any browser. The one-keystroke paste needs the bridge, and today the bridge runs on Windows.
Draw the line where the power is
Promtly has two parts. The board, where your prompts live, is a web page. A web page runs inside a browser sandbox, which normally prevents it from focusing and typing into unrelated native windows. Clipboard access depends on browser permissions and user interaction. Those limits matter, but the page still handles prompts and sends commands to the bridge. Its behavior remains part of the trust decision; publishing or reviewing it can be useful too.
The second part is the bridge, a local process, and it exists precisely because a web page cannot do three things:
- Answer a global hotkey, a chord pressed while some other program has focus.
- Put focus back on the window you were in when you pressed it.
- Press the keys: write the prompt to the clipboard and send Ctrl+V.
That is the part with real power over your machine, so that is the part that is
now public. The repository is two files that run, promtly-bridge.mjs and a
small promtly-bridge.cmd launcher, plus a README, a contributing guide and a
CI workflow. The script is about 2,100 lines of JavaScript that imports nothing
but Node's own standard library. The CI enforces that on every push: it fails if
a package.json or node_modules appears or if any import is not a node:
built-in, and it checks that the file parses on Node 20, 22 and 24.
No dependencies is a choice that is easy to underrate. A program with forty transitive packages asks you to trust forty authors. One file asks you to read one file.
What the code actually promises
The README makes five promises, and each one points at a line you can find:
- It binds to 127.0.0.1 only. The server is started with
server.listen(PORT, "127.0.0.1"), rather than exposing a network interface. This limits direct network access; it does not exclude every local process. - Its configured upstream is promtly.dev. The source fetches the board and checks for updates there. This describes configured requests, not an audited guarantee about redirects or every future version.
- It checks browser origins. Mutating requests require an allowed
Origin, which limits requests from other browser sites. A native local caller can supply that header, so it is not authentication of local processes. - It checks before it types. It raises the target window, confirms focus actually landed, and declines to send Ctrl+V if it did not.
- It keeps nothing of yours. Prompts live in the browser's storage. Text it captures is held in memory and never written to disk.
The fourth is the interesting one, because it is where the platform pushes back. Windows does not let any program grab the foreground whenever it likes. Microsoft's reference for the relevant call is blunt about it: "The system restricts which processes can set the foreground window." When a program is refused, Windows flashes its taskbar button instead of switching, and the call simply reports that it failed.
A tool that ignored that return value would go on to press Ctrl+V into whatever did have focus. For a launcher that is the worst failure available: a prompt, which may contain anything you saved in it, typed into the wrong window. So the bridge treats a refused switch as a stop. It would rather tell you to paste yourself than paste somewhere you did not choose.
The README is also precise about what the bridge does write to disk: a theme file you can edit, a cached copy of the board so the launcher opens offline, a reference file for customising it, the source of its PowerShell helper in the temp folder, a backup of the previous version when you take an update, and a Startup entry only if you ask for one. "Stores nothing" would have been simpler to write, and it would not have been true.
Why it serves the page itself
One design choice looks odd until you know the browser rule behind it. The
bridge does not only listen for commands. It also serves the board itself, on
127.0.0.1:37222, as a mirror of promtly.dev.
The reason is a change in Chrome. Under its Local Network Access work, a public
website that tries to reach your own machine now needs a permission prompt, a
defence against sites quietly probing routers and local services. A page on
promtly.dev calling 127.0.0.1 directly is exactly that kind of request. Served
from the bridge instead, the page and the bridge share one origin and there is
nothing to ask for. Because the mirror is cached, the launcher still opens with
no connection at all.
Updates are offered, never applied
A local program that updates itself is a program whose code can change after you
read it. The bridge checks for a new version every six hours and, when it finds
one, shows a badge. Nothing is replaced until you click it, the previous file is
kept beside the new one as a .bak, and the new code runs only after you restart
the bridge yourself. The source comment explaining this says replacing code
without being asked would be "a different trust relationship" from the one you
agreed to by downloading it.
Check the bytes, not the claim
Open source has a gap that is rarely mentioned. The code you read on GitHub and the file you actually download are two different files, and nothing forces them to match.
So here is the check, done this morning for version 0.7.2. The file in the public
repository and the file served at promtly.dev/bridge/promtly-bridge.mjs both
hash to:
2f116a143dfedcfd4c1743d4f5630e8eae49f2a6b638bfe8df373aa86728d985
You can repeat it in one line, and you should rather than take a figure printed here on trust:
curl -s https://promtly.dev/bridge/promtly-bridge.mjs | sha256sum
On the maintainer's side, the deploy for promtly.dev refuses to ship if its copy of the bridge has drifted from the public one. That is a real control, but it is the maintainer's own, and the hash above is the part you do not have to take on faith.
Two models need two chair briefings
The bridge source includes named-chair routing, but that does not establish that the hosted interface exposes a complete two-window workflow. This entry's original claim that one click seats both Parley chairs was wrong.
Parley keeps a shared document, revisions and a review through MCP. Connect the server in each model's client. The first model opens a table and returns the other chair's briefing, including that chair's private key. Send that briefing only to the intended second model. Sending the same key to both defeats the separation between chairs.
The Promtly pack supplies pads for those steps. Importing pads does not install MCP, identify the correct conversation or establish agreement. The revised preview lets a person inspect filled text before copying it. Native paste additionally depends on the running bridge and its target.
Astra's usage reset subsequently landed on September 19. The resulting review, including objections and their outcomes, is linked from Parley. This morning's article predates that review and is not evidence that native paste delivered it.
What is missing
It runs on Windows only. The board works in any browser, but pressing keys is
done per platform, through the Windows user interface APIs. The README names
macOS and Linux support as the most valuable contribution the project could get,
and the code is laid out for it: everything above one class, WindowsDriver, is
platform-neutral.
Where to find it
The bridge is at github.com/reisebusiness/promtly-bridge. The launcher itself is at promtly.dev, and the set-up page is promtly.dev/bridge.
Publishing the bridge makes the part that presses keys available to inspect. Matching the download to that source is a useful check. The interface that chooses the prompt and destination also matters, and neither source access nor a matching hash proves that the whole system is safe or correct.
Source links
- promtly-bridge on GitHub: source, README and licence (version 0.7.2, commit ddd6109)
- promtly-bridge CI workflow: the no-dependency check and the Node 20/22/24 matrix
- The served bridge file at promtly.dev, the one hashed above
- Microsoft Learn: SetForegroundWindow function (winuser.h)
- Chrome for Developers: New permission prompt for Local Network Access
- Promtly
