Session resources

Interaction

Group headers use Webpage, VM, Desktop, Terminal, Application, Container, Remote environment, or Other resources in that order. Empty groups and closed/exited resources are omitted. A Page used on several branches is one resource: it is listed once, as the viewed branch's row when that branch used it, otherwise its newest row. Unknown connection state stays in its original type. The existing row action buttons are unchanged. Type collapse is stored per session. Selecting a non-web view hides the web preview without closing its Page.

A Session resources navigation button sits in the right sidebar beside Files and Activity. It uses their shared row, icon and label classes, left-aligned label, 20px animated icon, and matching hover/focus behavior. Files, Activity and Resources remain the existing vertical navigation. It opens a panel in the existing resizable right dock. The dock toggle collapses the panel to its icon rail. Only resources whose recorded owner matches the selected session appear, grouped by resource type. Child-agent resources appear under their resource type with their actual owner identified. Switching sessions resets details and aborts previous requests. An owned webpage retains its recorded session context; drafts and unassigned views show no session resources. Legacy records retain their session checks; missing branch names do not create a display group. A resource row click selects a read-only chat preview; it does not activate or recreate the Page, change the user's tab layout, or steal tab focus. Explicit Open page shows the same existing Page as a regular top-level tab and hides that preview; returning to the conversation restores the preview unless the user hid it. Repeated opening reuses that Page without duplicates. Hidden agent-opened pages stay retained in Resources and do not add top tabs until that explicit action. Resources has no Pin control. Other resources show their details while keeping the resource panel available. Collapsing the dock or selecting another dock view stops resource polling. The selected dock view persists across reloads.

Sources and ownership

The registry records use of complete software/environment objects, not code execution. Integrations must identify the actual container, VM, application or remote environment. Per-command Docker image invocations and SSH subprocesses do not register resources. ProcessStore is used by Activity and is not projected into this list. The registry does not scan the host or infer objects from arbitrary shell text.

Boundaries

The server checks session and execution authorization before returning resources. Browser rows remain renderer-owned; requests for backend rows cover only the selected session. Rows returned through authorized descendant scopes are still filtered by their actual session owner. Registry payloads contain bounded display fields only; URLs omit credentials, query parameters and fragments. The resource panel participates in the existing right-dock layout. Native browser bounds resize with the remaining center area, keeping resources and the webpage visible together.

The Chrome reference supplied by the user motivates searchable grouped resource rows. The approved placement is the right collapsible panel. The implementation reuses the existing right dock, center-tab store, authorized resource route, and native browser bounds reporting. It does not introduce a second browser manager or a generic destructive action protocol.

Conversation preview and Page access

A preview stores the conversation ID independently of the reusable chat tab ID. Navigating within a chat tab or through its history displays only the selected conversation's preview. A conversation without a selected Page displays no preview; returning restores its own selection. Hiding a preview does not release or reveal the Page.

A retained agent Page that has not been opened as a top-level tab is private to its recorded conversation. Page inventory, turn context, screenshot, resolve, activation and close enforce that ownership using trusted execution session attribution, independently of the selected UI tab. Explicit Open page exposes the existing Page as a regular tab: other conversations may discover it and acquire it only when the existing exclusive Page lease permits acquisition. Exposing a Page changes discoverability, not its original provenance or preview ownership. Closing the tab removes its previews. An asynchronous result must still match the current access scope before delivery.

This extends the existing renderer-owned tab provenance and server-owned Page lease; it introduces no alternative browser registry. Existing GUI Agent preview and built-in-browser references remain authoritative. Acceptance covers same-tab conversation navigation and back/forward, independent chat tabs, private-page discovery and exact-ID rejection, explicit public opening, busy-Page rejection and acquisition after release, and access changes while native operations are pending.

Implementation status: implemented and independently reviewed. Regression tests verify conversation-bound previews, private and public Page access, asynchronous access revocation, trusted session attribution and cleanup, and exclusive Page acquisition. Web tests, browser E2E, full Python checks, type checks, production build and documentation checks pass. Live provider sessions remain a separate acceptance environment.

Acceptance and implementation status

Verify right-sidebar placement, absence of a top-left resource button, per-session isolation, resource type grouping, session switching, search/collapse, pointer and keyboard behavior, native-browser coexistence, row-click preview, explicit Open page of the same Page, chat preview hidden while that tab is active, no Resources Pin control, exclusion of code/process/file entries; inclusion of persistent Terminal environments, VM/desktop registration, cross-session authorization, normal/exception/terminated-owner cleanup, and reload behavior. Backend tests confirm Docker/SSH code execution does not register a software object. VM attachment tests use a controlled adapter.

Implemented: trusted software usage registration, authorized session projection, and the right-side panel. Controlled tests cover normal, exceptional and stale-owner release, scope authorization, and heterogeneous UI projection. Real Docker engines and VM endpoints are separate live environments. Native application and VM controller adapters remain separately planned. Canonical Resources/preview interaction: GUI Agent Resources and operation preview. Canonical web behavior: built-in browser.

Unified resource interface

Resources identifies persistent environments. A Terminal resource is the existing PTY and shell, not a command transcript. Web, Terminal and installed applications share discovery, identity, session attribution, capability descriptions and view selection. Their existing providers retain execution authority and type-specific operation schemas.

Unsupported actions return an explicit capability error. A common interface never invents close, pause, screenshot or keyboard support for a provider. Structured observations retain images, output cursors and typed results. Existing web_use and terminal_use remain compatible public entries. A resource identifier is not an access grant.

Trust and failures

The worker derives the session, execution and originating window from trusted context. Providers retain ordinary tool approval, sandbox checks, private-resource checks, exclusive bindings, generation checks and input revisions. Application manifests cannot provide arbitrary host code through a renderer request. Third-party resources use installed and explicitly trusted application packages. Desktop availability is reported without substituting another host. Uncertain writes are never replayed automatically. Hiding a view, releasing Agent access and terminating an environment are separate operations.

Shared interaction

The right sidebar presents one session-filtered list with common grouping, status and selection. Terminal rows participate in the same list rather than an appended independent section. Selecting a Terminal attaches an interactive view to its existing PTY; it must not create a new shell. Switching sessions clears the selected view. Web retains its native Page preview and explicit top-tab action. Terminal input remains available while the conversation is visible. Close controls identify the environment they terminate. Output is untrusted content and input acknowledgement does not mean command completion.

Framework comparison

The existing Page registry provides native target ownership and observation freshness; it is retained. The shared Terminal manager provides generation, binding, output cursors and native receipt correlation; it is retained. The Applications runtime provides installed manifests, instances and declared operations; it is reused for user software. The existing resource_use context manager supplies display-only lifetime reporting; it cannot provide control by itself. A second browser registry, a universal shell-command fallback and an unrestricted renderer plugin loader are rejected because they duplicate authority or bypass provider constraints.

Acceptance

Verify session isolation across heterogeneous resources; capability rejection before effects; existing Page identity across previews; user and Agent observing the same Terminal cwd, environment and output; release without process termination; changed-generation rejection; blocked conflicting human fragments; no write replay after a lost receipt; hide without close; actual exit before restart; application operations constrained to declared exposure. Check the complete Web and Desktop suites, Python contracts and affected resource suites, full repository verification, native platform CI and the installed default App.

Implementation status

The source implements the common resource tool, JSON Schema capability descriptions, trusted Python provider registration, Web and Terminal adapters, and a shared session list with an inline same-PTY Terminal view. Independent specification and quality reviews pass. Complete local candidate verification passes; native CI for these changes and installed-App acceptance remain pending. Installed application adapters and their same-instance views are included in the backend-parity extension below. Operating-system desktop input control is separate from installed application operations. Packages require explicit installation and trust before automatic provider discovery. This section does not claim merge or release completion.

Backend operation parity and installable providers

Every product operation has an authenticated backend entry. HTTP operations are described from the registered API schema; existing WebSocket business commands are also callable through a request/response backend adapter using the same handlers. The Agent discovers a named operation and invokes it with structured arguments. It never needs to inspect or click the OpenProgram interface to perform a framework operation.

Authority and boundaries

The framework tool requires the existing owner authority and tool approval, refuses an active sandbox or a nonlocal backend, and never returns owner credentials. Internal authentication, native receipt and connection-registration endpoints are transport internals, not callable product operations. Renderer preferences, navigation and native window functions have explicit backend commands addressed to an exact connected window. Replies are correlated to that connection; disconnects and uncertain mutation results do not trigger retries. Browser and Terminal resource operations preserve their original provider checks. Application operations retain explicit Agent exposure and installed-package trust.

Automatic application integration

An enabled installed application automatically provides application.<id> in the resource catalogue, without process restart or a hand-written registry edit. Its manifest describes operations and input/output schemas; open binds its durable instance to the current session, observe reads state and runs, act submits a declared Agent-visible operation, release removes only the session association. Cancellation and question answers operate on the exact instance and run. The same instance opens in an isolated application view from Resources. Disabled, removed or updated applications revoke stale descriptors. A scaffold command creates a runnable package whose interface and Agent use the same backend operations.

File organization

Resource contracts and dispatch live in openprogram/resources, adapters in its providers package. Framework discovery, authority and client calls live in openprogram/framework. Server routes remain under the Server application, grouped by control responsibilities. Interface command handlers live under apps/web/lib/framework and resource views stay under components/session-resources. Compatibility imports preserve existing integrations. New modules have a single responsibility; no unrelated repository-wide file moves are included.

Verification

Test backend discovery and invocation without a rendered frontend; reject invalid operations, unauthorized contexts and unsafe paths before effects. Verify automatic install/disable/update/remove discovery; real application execution without an iframe; resource session association, version checks, state concurrency, cancellation and view reuse. Verify exact-window interface receipts and no retry of uncertain mutations. Check that frontend HTTP/WS operations are covered by the shared backend catalogue and that registered interface commands match their declarations. Run independent specification and quality review, repository-wide local checks, and retain native CI and installed-App acceptance as separate gates. The running default App is not restarted while the user has prohibited interruption.

Implementation status

The source includes backend operation discovery and invocation, explicit window commands, automatic installed-application providers, session associations, same-instance views and package scaffolding. Independent specification and quality reviews pass after repairs to Agent exposure, approval-policy isolation, Page authority, repeated resource selection, profile controls and error propagation. Public-entry tests, the complete local Python test layers and coverage gate, Web tests and production build, Desktop checks, browser E2E and documentation checks pass. The combined local App candidate also passes its complete Web checks. Native CI for these changes and installed-App acceptance remain pending; this design does not claim release completion. Window presentation requires a connected view, while backend business and application operations work without a rendered frontend.

Session scope in split canvases

Files, Activity, Resources, the resource snapshot request and the drop targets share one conversation scope. The sidebar owns the single window-level resource projection so a mixed canvas cannot display one conversation while polling another. Clicking a conversation selects it immediately. Focusing a webpage or file pane retains the last selected visible conversation in the same canvas; a canvas with a single conversation uses that conversation when opened on a webpage. Hidden or unrelated conversations are not fallback owners. Standalone resources retain their recorded session attribution.

Dropping a webpage on Resources attaches it to the conversation shown by that panel. A split tab containing one webpage attaches that webpage only; for a split with multiple webpages, drag the desired page's pane handle. Both top-tab and pane-grip drags use the same blue region preview as canvas docking, with a visible release-to-add label. Hovering the Resources navigation row highlights it together with its visible panel; leaving or cancelling clears the preview. Release waits for native transfer cancellation and the confirmed association, then opens Resources and shows a success notification. Failed attachment shows a visible retry message and preserves the page. The existing Page and its layout are retained; association does not change page provenance. Acceptance covers chat/web splits, two chats plus a webpage, hidden conversations, hover/cancel/release and correct request session IDs.

Implementation status: targeted Resources and drag regressions pass; specification and quality reviews pass. Installed-App acceptance is verified separately.

Closing a resource tab

A tab is a presentation of a Page. Closing a top-level tab or split pane hides a session-associated Page without destroying its native view, navigation state or resource associations. This applies to Agent-created Pages and manually opened Pages later attached to a conversation. The same Page can be reopened from Resources. Closing an unrelated conversation does not close its retained Pages.

Human tab-close actions resolve current ownership when the close animation completes. A standalone Page with no session association is removed and its native view is destroyed. Explicit Close webpage in Resources and authorized Agent close remain destructive operations. Hidden Pages leave split groups and cannot become the active fallback; focus moves to another visible tab, or the center becomes empty. Retained visibility is persisted without changing creator attribution or publishing a private Page.

Verification

Exercise the shared tab store, resource projection and native reconciliation with reveal, navigate, close and reopen. Verify Agent-created and manually associated Pages, split/bulk closure, standalone destruction and explicit resource destruction. Implementation acceptance and installed-App evidence are recorded separately.