Skip to main content

​
Workspaces and deployments

  • Nothing crosses a workspace. Every query is scoped to one workspace in one place in the code. No query, prompt or playbook ever reads another workspace’s data.
  • Your agent sees one workspace: the one picked when it signed in. A CLI login is tied to one workspace. An OAuth sign-in (plugin, Cursor, Codex, VS Code) is tied to the workspace picked on the consent page, and only while you’re still a member. Picking a different workspace signs that app out everywhere else.
  • One deployment per call. Every deployment tool names one deployment and returns only that deployment’s data, plus the playbooks it uses. No call returns two deployments’ data. A plan change that cites another deployment’s documents is refused.
  • Only local agents. The consent page only grants access to agents whose sign-in returns to your own machine, so a look-alike website can’t be approved.
  • Disconnect anytime. Settings → Connected agents lists every CLI login and signed-in agent. Disconnect revokes it, refreshed tokens included. Logins and connect codes are stored only as SHA-256 hashes.

​
Quotes are checked in code

Every item in a plan quotes a source. Before anything is stored, the quote is checked to be an exact passage of that document (ignoring case, spacing and quote style) and at least four words long. A quote that isn’t there is dropped, and an item left with no quote is dropped too. This applies to plans OpenScaffold builds, plan changes it proposes, and plan changes your agent proposes.

​
What changes on its own, and what waits for you

Right now, every change to the plan waits for you under Needs you. OpenScaffold can’t yet prove who wrote a document, or that it’s really you approving, so nothing changes the plan on its own. Coming next: you confirm your customer’s files once, on your phone; after that, new statements from the customer’s own people in that material update the plan by themselves, with Undo. A passing review still marks the work it found met as done, with Undo. That changes status only. Your coding agent can propose changes and record what people said or what you decided. Nothing it sends becomes binding: you approve it in OpenScaffold. Even once updates apply by themselves, these will always wait for you:
  • removing scope;
  • contradicting anything someone on your team wrote or decided;
  • commands;
  • every change your coding agent proposes, reports or records;
  • every playbook entry.
Code decides what may apply on its own, from where the words came from; a model can make a change wait, never make one apply. (A review’s “met” grade is a model’s reading of the diff; it only marks work done, never changes what the plan asks for.) Every version is kept, and undoing or rolling back adds a new version.

​
Playbooks hold no customer data

Every playbook entry, however it’s added, goes through a leak guard first. It refuses an entry that mentions any deployment’s name, customer name or email domains, any email address, a stakeholder’s name, a customer’s systems or terms, or copies six or more words in a row from any customer document.

​
Customer documents are data, not instructions

When a model reads a customer document, the text is fenced off and the model is told that anything inside is customer content, not instructions to follow. The backstop is the rule above, applied by code: only new quotes from the customer’s own people apply on their own. That includes a goal the customer restates in their own words; the old goal’s quotes are kept as history. Two things your coding agent supplies count as its report, not the customer’s words:
  • files it sends after the first plan (add_document, add_documents, CLI uploads);
  • conversations it records with record_conversation, at any time.
This holds whatever author, email address or side the agent names. Both are kept and searchable, but any change they would make waits for you. An item that rests only on them is marked as not confirmed by the customer: unverified, or documented when the agent says the person is from your company or a supplier, or the FDE’s when it says the person is the FDE.

​
Where your customer’s code runs

OpenScaffold never runs your customer’s code, on its servers or on your machine. It reads what the customer said and briefs your coding agent, which writes and runs the code on your machine. The CLI runs only read-only git commands and claude (to connect Claude Code). Playbook environments are stored as text and never run.

​
Where data goes

  • Storage: documents, plans and the search index are in Postgres (Neon).
  • Models: reading documents, building plans and proposing changes use Anthropic’s Claude (claude-opus-5-5) through Vercel’s AI Gateway. Search embeddings use Voyage (voyage-4-large) through the same gateway.
  • Connected tools (Gmail, Slack, Linear and others): Nango holds the OAuth tokens and runs the syncs, and caches synced records on its side. OpenScaffold stores only which integration is connected, and the documents that match a deployment. Nothing is pulled in until you pick what feeds a deployment; an empty pick matches nothing.
  • Logs: no customer content beyond ids. Agent tool calls record the tool, its arguments (search queries included; long text is replaced by its length) and the result count.
  • Deleting a deployment deletes its documents, search index, plan versions, proposals, sessions and sources.