One Agent, several workspaces: verify the write destination before changing data

One Agent can serve several teams through multiple accounts and workspaces. A request to update the customer table then loses its unique address: hosts can contain similarly named Bases, and one credential may access several Spaces. A successful command only establishes that an accessible destination accepted it.

A wrong destination need not produce a permission error. Pin each task’s host, identity, Space, Base and record, especially when other terminals can change shared active configuration.

Understand configuration resolution

CLI precedence is individual flags, --config, --profile, the active account’s .env, then defaults. Exported environment values override disk configuration. Inspect the command and relevant overrides without printing token values.

An account switch rewrites shared ~/.busabase/.env. Skills and scripts that read it follow that switch. Two concurrent terminals should therefore not depend on shared active state as an immutable per-task destination.

A command-specific profile reads that account directly without changing the shared file. An independent config file is another option. Pin the base URL and Space ID in automation, and keep credentials out of visible command transcripts and audit records.

Identify five layers of destination

The CLI account guide distinguishes credentials from workspaces. One Cloud account can belong to multiple workspaces. The CLI calls a workspace a space, using --space-id and the x-busabase-space header. A self-hosted server reports its single workspace.

A write also needs a host, Base and record. Retain the host, account/profile, Space ID, Base ID and record ID, or a stable business key for a new record. Check Folder containment when relevant. Human-readable names help review, but do not replace resource identity. A credential with access to many resources does not establish which one this task intends.

Give each concurrent task its own destination

Active account switching is convenient for manual work. Parallel scripts and Agents benefit from explicit profiles or independent config files plus pinned host and Space. Changing one task’s destination should not silently change another’s shared dependency.

Start with one recurring write: explicit destination, read-only comparison, bounded proposal and canonical readback. That produces evidence of where the data went.

Perform a read-only identity check

Read whoami under the intended configuration, then inspect the Folder and Base’s actual identity, containment and schema. For an update, read the current record and head to confirm both its Base and business meaning.

Return a secret-free comparison of expected and observed host, account alias, identity, Space, Folder, Base, record and allowed fields. Expected IDs must come from the authorized task; do not invent both sides of the comparison.

Pause on a host mismatch, inaccessible Space, wrong Base containment, ambiguous names or a record that does not match the job. Do not substitute another similarly named table or try other accounts merely to obtain a successful command.

With the specified profile, base URL and Space ID, read the identity, Folder, Base and target record. Compare them with the task’s IDs and list matches or conflicts without exposing credentials. Do not switch shared active configuration, modify settings or submit changes before confirmation.

Carry the target into the proposal

After verification, use the same explicit configuration for a narrowly scoped ChangeRequest. Identify the task, resource and allowed fields, checking the current record version before an update.

Record writes retain an auditable change path. A write-level credential can result in an immediate merge; other changes may wait for review. A returned proposal does not by itself mean canonical data changed, and pending review is not a failed write.

Honor any requested human-review boundary. Destination verification does not approve the proposed content. Do not create unrelated production records as a connection test.

What a successful connection still does not establish

whoami helps establish identity, but the business job still needs Base and record verification. Put expected IDs in the task and read actual containment; finding a similarly named table is not proof. Check schema too: similar titles may serve different business processes.

For concurrent jobs, carry a profile or separate config and explicit host and Space as task parameters. Shared active configuration is convenient for manual switching, but fragile as the only destination source for several jobs. Before changing it, identify other runs that depend on it.

Read the actual result back

Inspect the CR’s real state and operation targets, then read the canonical record from the pinned host, Space and Base. Verify intended fields, record identity and fields that should remain untouched. Exit code zero alone does not prove the landing point.

After a timeout, inspect the original CR and canonical state before retrying. Retain a stable business key and original proposal for creates rather than submitting a second record while the first outcome is unknown.

An existing execution Base can hold host, account alias, resource IDs, allowed fields, original head, CR ID, merge state and readback evidence. This is a suggested audit design, not automatic isolation, and must contain no token values.