Configuration

The account service belongs to OHarness Cloud. The client knows only its public origin, not the Supabase project or Composio project API key.

Location	Responsibility
~/.oharness/config.json	General runtime preferences: models, permissions, logging, sync
~/.oharness/cloud.json	Optional public Cloud address: { "siteUrl": "https://oharness.ai" }
~/.oharness/plugins.json	{ "runtimePlugins": [...] }; optional plugins for declarative bundles
~/.oharness/mcp.json	{ "mcpServers": { ... } }; Web connector changes write here
Cloud deployment environment/secrets	Supabase configuration and platform-owned service keys
Credential store	User login credentials; not any of the config files above

OHARNESS_HOME redirects all four client files. The official Cloud origin is the default; self-hosted/development overrides use OHARNESS_SITE_URL, then cloud.json, then the packaged public origin. HTTP is allowed only for loopback development. Repository config cannot choose the Cloud origin or load runtime plugin code. Programmatic Harness.create({ config, runtimePlugins }) still supports explicitly supplied configurations.

Compatible migration

Existing config.json sections are read only as a fallback while their separate file is absent. An existing separate file is authoritative, including an empty plugin list or empty MCP map. Legacy account.siteUrl is accepted; legacy Supabase fields are no longer used by the client.

npm run config:migrate             # Preview filenames only; no secrets printed
npm run config:migrate -- --apply  # Back up, split, then clean the old sections

The migration preserves unrelated preferences and does not overwrite existing split files. It saves a private config.before-split.<id>.json backup and writes the general config last. Files are atomically replaced with mode 0600. Do not edit config concurrently with migration or run multiple migration processes. The backup can contain old credentials: keep it private and remove it yourself after verification. Migration never modifies login credentials or authorizes apps.

Account transport

Browser login still uses Cloud /auth/desktop and /api/desktop/exchange. Refresh and terminal OTP fallback now use /api/desktop/auth/refresh, /otp, and /verify. Update Cloud before restarting an updated client. An older Cloud returns an explicit error; the client does not fall back to direct Supabase calls.

Cloud uses its configured auth project, validates inputs, limits requests and response sizes, and returns only session fields. Tokens are never logged or included in errors. Requests are not automatically retried; responses are no-store. Newly acquired credentials record their Cloud origin; changing it requires signing in again before refresh. Legacy credentials acquire this origin on the first successful refresh against the current trusted Cloud address.

The Cloud endpoint's rate limit is per process. Production deployments should also enforce shared edge rate limiting. Website Supabase settings remain in the Cloud project; no database schema changes are required for this migration.

The hosted [Cloud connector](cloud-connectors.md) keeps the Composio key and app allowlist in Cloud. Its built-in connector-cloud runtime plugin shows Web chat authorization cards and resumes the waiting tool after verified binding. plugins.json controls the plugin switch; it contains no platform credentials.