Publishing is a form of authority.

A coding agent reads material from many places: files, issues, tool results, and sometimes the web. Giving that process a publishing integration adds the ability to affect a public account. The important design question is what authority the process receives and what limits remain outside it.

capx café keeps the X access token in a server-side vault. The local agent receives a short-lived, revocable session handle that lets it request guarded actions. The handle still carries authority and should be protected. It is not the X token and does not enable direct X API access.

Follow the token, not just the button.

Account authorization happens in the browser. X redirects to the capx café service’s callback, and the service seals the resulting token in its vault. The token is not placed in the agent’s configuration file.

A publishing request follows the server’s admission checks, the casserole guardrail, and then the vault and X adapter. A blocked request does not reach token decryption. Calling the same service directly still goes through the guardrail; the check is part of the server’s publishing path.

The boundary in one line

Agent request → admission → guardrail → vault → X

The agent supplies the text. The server decides whether the request can proceed.

What the six layers check.

casserole applies deterministic checks for eligibility, rate, quality, authenticity, monitoring state, and audit. Depending on the result, a request can pass, need a rewrite, be held for review, or be blocked.

The quality rules include signals such as vague hype, engagement bait, and near-duplicates. Eligibility and rate checks consider whether publishing is permitted under the account’s current conditions. The decision is recorded so it can be inspected later.

These rules do not rely on a second language model judging the draft. They provide a defined control at the publishing boundary. Their scope is narrower than “everything a human reviewer might notice.”

What a passing verdict does not prove.

  • It does not fact-check every statement. A post can pass and still contain an inaccurate claim or an unwise disclosure.
  • It does not moderate media. Attached images and videos are not content-inspected by casserole.
  • It does not remove operator trust. The hosted service operator controls infrastructure containing the vault; a self-hoster becomes that operator.
  • It does not control X. Platform outages, account actions, and X-side limits remain external conditions.

A compromised session can still attempt guarded requests until the handle expires or is revoked. Keeping the token away from the agent narrows the credential exposure; it does not mean the agent has no publishing ability or that every allowed post is harmless.

Use the controls in your daily workflow.

Start with preview, read the draft, and approve the actual words. If a request is blocked or held, inspect the reason and correct the issue. Use the audit trail to understand the result, especially when a send status is uncertain.

Try this with your agent

Preview this draft through capx café. Show the verdict and the stated reasons. Separately flag unsupported claims or details that may be private. Do not publish, alter a schedule, or try another route if the request is blocked.

The homepage demo shows the real guardrail in a sandbox with X publishing simulated. The source and adversarial tests below let you inspect the implementation and its stated boundaries in more detail.

Sources & further reading