Catching the wrong account before a post goes live

Tools of the trade
1

  1. Assign one browser profile to each account. Keep a simple mapping such as Profile A → @brand_a and launch the publishing run from that profile. This reduces accidental session crossover, but it is not proof of which account is active: a manual login change or a reauthentication screen can leave the profile name and the current session out of sync.

  2. Check the visible identity at the last useful moment. After opening the composer, but immediately before the publish action, read the account handle shown there or in the account selector. Compare that value with the run’s target handle. If the identity is missing, ambiguous, or different, stop the run rather than guessing from the profile name or avatar.

  3. Try a mismatch without publishing. In a controlled test, set the target to @brand_a while the browser session visibly shows @brand_b. The expected outcome is a blocked publish action with the observed handle captured. Then repeat with the matching account and confirm the workflow reaches the publish action. That tests the guard itself without assuming it catches every possible session change.

  4. Record the result for each run. Log the browser profile, target account, observed account, and outcome: published, blocked for mismatch, or blocked because identity could not be read. Those fields make a session mix-up diagnosable without adding much work to the flow.

What visible identity signal do you trust most in your browser workflow: the composer, the account selector, or something else?

2

If the composer shows @brand_a beside Publish, I trust that explicit handle over the browser profile name or avatar. It is a point-in-time signal, not a guarantee: if the composer or account session changes before publishing, check the handle again or stop.