publish-through-a-browser-already-signed-in

Post to a platform that has no usable API by driving a browser a person signed into by hand, and check the result as a stranger rather than as the author.

Procedure

  1. start start. Goes next to s1
  2. check The signed-in browser is up and answering. Goes on_fail to s2; next to s4
  3. action Start the browser by hand on its own profile, RO (read-only). Goes on_fail to s11; next to s3
  4. check The port answers now. Goes on_fail to s11; next to s4
  5. check The session in that profile is still signed in. Goes on_fail to s11; next to s5
  6. action Connect to the running browser, never launch one, RO (read-only). Goes on_fail to s11; next to s6
  7. action Write the post as a draft, RW (reversible-write). Goes rollback to s10; on_fail to s11; next to s7
  8. check The draft carries the whole body. Goes on_fail to s11; next to s8
  9. action A person presses publish, RW (reversible-write), requires approval. Goes rollback to s10; on_fail to s11; next to s9
  10. action Withdraw it, back to a draft, RW (reversible-write). Goes next to __end_aborted
  11. check Open it from a profile signed into nothing. Goes on_fail to s11; next to __end_success
  12. end aborted. Terminal
  13. escalate Escalate to whoever owns the account. Terminal
  14. end success. Terminal

Open the graph on its own page — larger, printable, and an address you can send.

Walk it without running it — you answer what your environment would answer, and the path, the capabilities, the approvals and the distance back to an undo come out of the document. Nothing executes; there is no Run button here and there will not be one.

Trust

T2 · attested 2026-10-11 · runbooks.directory

Nobody has attested this record. That is the ordinary case: T2 is what the catalog can check on its own, and T3 needs somebody to run the procedure and sign for it.

  • Link liveness has not been checked: it needs a network and the catalog builds without one. Run pnpm gates --online where there is one.

Steps

  1. s1 check — The signed-in browser is up and answering
  2. s2 action — Start the browser by hand on its own profile (read-only)
  3. s3 check — The port answers now
  4. s4 check — The session in that profile is still signed in
  5. s5 action — Connect to the running browser, never launch one (read-only)
  6. s6 action — Write the post as a draft (reversible-write)
  7. s7 check — The draft carries the whole body
  8. s8 action — A person presses publish (reversible-write) — requires approval
  9. s9 check — Open it from a profile signed into nothing
  10. s10 action — Withdraw it, back to a draft (reversible-write)
  11. s11 escalate — Escalate to whoever owns the account

Capabilities

This is a privilege request. Check it against your own allowlist before running.

  • cli:curl — used by s1, s3

Provenance

Source
https://runbooks.directory/r/std/publish-through-a-browser-already-signed-in/source.md
Fetched
2026-09-04
Source last checked
not since it was captured on 2026-09-04 — recorded as current
Licence
CC-BY-4.0
How it got here
Written by this catalog's maintainers and reviewed in full.
Highest risk in this procedure
reversible-write

Take it with you

Run it under supervision

Runs here, on your machine, under supervision: every step is proposed before it happens, an approval gate stops for you, and a failed expectation goes where the procedure says rather than on to the next step. Nothing is sent anywhere. To supervise an agent that is doing the work instead, runbooks hook sits in its tool-call path.

npx @runbooks/cli run std/publish-through-a-browser-already-signed-in@1.0.0 --as "$(whoami)" \
  --input debug_port=<the debugging port the signed-in browser is listening on> \
  --input profile_dir=<the browser profile directory holding the session for this account>