.fused/workspace.yaml, or split selected declarations into .fused/services/**/*.yaml files with type: services. Local files reach the Engine only through plan and apply.
Add and activate it
workspace service add is the discovery command as well as the authoring command. It checks the services already enabled in your workspace first, then searches the Registry only when needed. In a terminal, it asks you to select an ambiguous match and confirms every Registry fallback.
--apply activates only the services this command added; it cannot remove an unrelated active service through a full-workspace mirror.
If no suitable Registry service exists, bring the API in yourself.
Creating a new SDK, API app, or MCP server? Start with
fused-cli init instead. It folds this activation into app creation and keeps separate workspace and app receipts.Choose how to authenticate
For a supported OAuth integration, use a Managed service to connect users through Fused’s provider application, or bring your own application credentials. Managed auth keeps Fused’s client secret on the broker and user tokens in your Engine. It still requires service activation, an available managed offering, and user consent. For API keys, basic auth, or other schemes, store the required credentials in your bucket.Inspect before you change anything
Use read-only search when you want to compare what is already enabled before starting an addition:workspace has matches the service name, not the slug. Use it as an exact check rather than primary discovery.
Need a controlled workspace diff?
Use the advanced controlled workflow when you want to author without applying, inspect the workspace diff, store a receipt elsewhere, or make broader policy changes. Omission is non-destructive: deleting a service declaration from a local file does not remove that service from the workspace. Explicit removal is a separate reviewed operation. Starting from nothing,fused-cli workspace init creates the skeleton, and --extend adds to it without replacing what is already there.
Flags
workspace service add
Terminal selection and confirmation are the default. The retained
--interactive flag explicitly requires that default behavior and fails when combined with --no-input or CI=true.
workspace init
Creation never replaces an existing file. Extension is additive and idempotent — re-running it reports
unchanged rather than duplicating a service.
Pull Engine state into local files
workspace sync refreshes only the local service declarations you select. It never mutates the Engine, and it never exposes a local source path to the shared UI or Engine.
.fused/workspace.yaml and .fused/services/**/*.yaml. --file scopes the pull to identities in that file. --service <service>[@<version>] accepts comma-separated values or repeated flags; omit the version to pull every active version, or name exact active versions without deleting unselected local versions. With --file, selected services share that destination; declarations in another local file transfer with authored policy intact. Without --file, each new service gets its own readable .fused/services/<service-slug>.yaml type: services document, with a stable identity suffix when readable slugs collide. Only --all imports every active service.
A local declaration missing from the Engine is retained and reported as inactive remotely. Sync only updates fields it owns, so other hand-written service fields survive.
When permission is the blocker
Finding a service does not mean you may add it. Planning needsworkspace.read and service.manage on every changed service; applying also needs workspace.update. The built-in Admin and Owner roles carry these. Builder and Viewer do not.
If you are denied, keep your draft and plan, and ask an administrator for the exact missing scope rather than working around it:
Bring your own API in
No Registry service yet? Import one from a spec, a GraphQL endpoint, or the provider’s docs.