Maintenance and Limitations

Maintenance keeps an Online version observable, stoppable, and safe to iterate without presenting internal APIs or unaccepted platform behavior as developer features.

Minimum post-launch acceptance

1. Confirm Online state

   The Agent detail page must show Online. “Published successfully” alone does not prove that the Agent is accepting production traffic.

2. Enter a production client from the public page

   Use the user_agent_url from the publication result, or find the Agent by its exact name in the public Agents catalog and verify its identity. Click Use in ChatGPT, or choose Use in Claude or Use in WorkBuddy from the split-button menu. Do not construct a public URL from an internal Agent ID.

3. Run a real invocation

   In the client, search for or select the current Agent by its exact name and verify its description and developer identity; a generic installation dialog does not itself bind the current Agent. Submit a representative minimum request and inspect the final output. If the Agent promises a file, image, or another artifact, open or download it. If the public page or installation entry is missing, record BLOCKED instead of substituting WebChat.

4. Record reproducible evidence

   Record the version label, invocation time, input type, visible result, and any failure code. Redact tokens, Cookies, private keys, and sensitive portions of connection commands.

Pause new invocations

For maintenance, a high-risk defect, or service retirement, click Take Offline on the published version page and wait until the page confirms Offline. Offline stops new production invocations; it does not delete the Agent, version, or historical records.

Take the Agent Offline before investigating a high-risk fault

If current behavior may cause incorrect delivery, unexpected cost, or data risk, stop new traffic with Take Offline before diagnosing the defect.

With explicit authorization, CLI 0.7.3 also exposes the corresponding allow-listed operations. Use oasn-sa-dev portal supply-status to change Agent supply state or oasn-sa-dev portal version-suspend to suspend a specific version, following each command's --help contract. These writes require confirmation and a stable idempotency key; command availability is not authorization.

Publish a new version

For a behavior change to a published Program, use the developer page to create or edit a draft version, then repeat Workspace development, WebChat testing, Agent Card/MOM/pricing validation, Publish, and Go Online. Never assume that a published runtime snapshot can be edited in place.

• Use a new N.N.N version label and describe the behavior change.
• Test normal input, attachments, and boundary/failure scenarios again.
• Confirm that the MOM still matches the actual input and output contract.
• If the Program uses a WebUI, verify every declared page through the current proxy link and the final oasn-webui output.
• After publication, repeat succeeded + visible + Go Online + public-page installation + real invocation.

Current Workspace lifecycle surfaces

Do not bypass the developer control plane

The current public gap is Workspace close—not WebUI-port configuration. Even if underlying services expose cleanup fields or private endpoints, do not call them. Use the 0.7.3 CLI for source, connection, resume, and port operations, and stop when an operation is not on its public allow-list.

Maintain an active Workspace WebUI

Always begin with the authoritative query:

oasn-sa-dev version webui-ports get --version-id <agent_version_id>

The two status fields answer different questions:

When the complete desired list changes, save it as a replacement:

oasn-sa-dev version webui-ports set --version-id <agent_version_id> --ports 7860,8765

An active Workspace applies this mapping in place. It does not rebuild the Sandbox, change the source, or restart the business process. Confirm both synchronization and proxy readiness, then test the real page and its nested routes. The old links become invalid after a mapping change.

Setting the same list again is an idempotent no-op. If the port list is correct but the link generation is expired or revoked and a new generation is explicitly required, first query the state and then, with explicit authorization, run:

oasn-sa-dev version webui-ports refresh --version-id <agent_version_id>

refresh retains every declared port and creates new links; it does not clear the list or rebuild the Sandbox. A 502 generally requires checking that the business service is listening before refreshing. For pending, a timeout, or a conflict, query with get and do not automatically replay the write. If the Workspace connection itself is expired and the developer wants to continue using it, renew that same Workspace with workspace resume.

Reopening WebUI results after a production task ends

Development Workspace links and production result links are different. A development link is temporary and cannot prove production recovery. For a production invocation, the platform is designed to restore the environment and original WebUI services from the snapshot committed for that same session when the user reopens its result link; the rule applies equally to one or multiple ports.

Snapshot restoration is integrated but not yet formal acceptance evidence

The current restoration path is connected in code, but it has not completed formal end-to-end acceptance. Do not promise that a result link can always be reopened merely because a snapshot exists, ports are declared, or the development page works. Test single-port and multi-port production results after task completion when an authorized production invocation surface is available, and otherwise mark the behavior NOT TESTED.

The platform does not require a developer-supplied fixed restart script or health endpoint for this restoration contract. It preserves the original port, path, query, and fragment, but does not reuse old network connections or recreate a page that the original process deleted. Never work around a restoration failure by reducing the Agent to one port, regenerating the original task, or reusing old task credentials.

When a Workspace expires or reaches a terminal state

The CLI's expires_at is evidence for the short-lived connection. Before expiry, save and verify the business work under /oasn. An active Workspace with an expired connection may be renewed only through the explicit workspace resume flow. The following lifecycle states cannot be used as a development environment:

• failed: creation or runtime failed; diagnose it with failure_code.
• closed: the Workspace is closed.
• published: publication moved this development Workspace to a terminal state.
• cleanup_pending / close_pending: the platform is finalizing it; do not upload or execute more work.

Recurring regression checklist

• Online state, a production invocation, and artifact downloads still work.
• Every WebUI declaration remains synchronized, every current proxy is ready, and the actual pages still load through their current links.
• External Plugins, MCP/A2A Tools, and resources have not drifted in permission or protocol.
• The MOM, website description, and actual Agent behavior remain consistent.
• After cost changes, gross margin and Minimum Starting Balance in Credits are reevaluated.
• Screenshots and commands match the current implementation baseline; after a CLI upgrade, regenerate and revalidate this manual.

For exact commands, return to CLI Reference. For port declarations and final reply syntax, see Input, Output, and WebUI.