Running Agents from CCAM

Running Agents from CCAM

CCAM can expose run-oriented workflows in addition to observing existing sessions. Treat any launch capability as an execution boundary: know which host, directory, provider, and credentials will be used before starting work.

Preflight checklist

• The target project path is correct and trusted.
• The selected provider is installed and authenticated on the execution host.
• The prompt contains no secrets that should not be persisted in history.
• The expected permissions and tool access are understood.
• An operator knows how to stop or recover the run.
• Monitoring hooks are healthy so the run will be observable.

During a run

Watch the session and agent tree rather than repeatedly launching duplicates. If the UI appears frozen, compare the durable session with CLI output before retrying. A second launch can create conflicting edits or duplicate spend.

After a run

Confirm the agent's claimed result against the actual project state. CCAM records activity; it does not replace source control review, tests, or deployment approvals. Capture the session ID in a change record when traceability matters.

Safe failure handling

If a run must be interrupted:

1. preserve the latest transcript and working-tree state;
2. stop through the narrowest supported control;
3. confirm child agents and long-running tools are no longer active;
4. record why the stop was necessary;
5. resume only after checking for partial changes.

Avoid enabling broad destructive controls merely to recover one run. See Security and Remote Access and MCP Workflows for permission boundaries.

When to launch elsewhere

Use the provider CLI directly when you need an interactive permission conversation, a one-off local experiment, or features CCAM does not expose. CCAM should still observe that session once hooks are installed.