Skip to content

Add workspace scoping to all existing RPCs #33

Closed

Description

@rhuss

Proto Gap: Workspace Scoping

All existing request messages now include workspace and/or all_workspaces fields for workspace-scoped operations. The SDK's existing types and converters don't thread these fields through.

Affected request messages (partial list)

Message New fields
CreateSandboxRequest workspace
GetSandboxRequest workspace
ListSandboxesRequest workspace, all_workspaces
DeleteSandboxRequest workspace
CreateProviderRequest workspace
GetProviderRequest workspace
ListProvidersRequest workspace, all_workspaces
DeleteProviderRequest workspace
ExposeServiceRequest workspace
ListServicesRequest workspace, all_workspaces
ExecSandboxRequest workspace
All SSH/TCP/Policy requests workspace

Implementation scope

  • Add Workspace field to types.Sandbox (from ObjectMeta.workspace)
  • Add workspace option to CreateOptions or as a parameter
  • Add workspace filtering to ListOptions
  • Update all converters to pass workspace fields
  • Update all fakes to respect workspace scoping
  • Tests for workspace-scoped operations

Design question

Should workspace be a field on the resource type (like Labels), or a parameter on each method call? The proto has it on requests, but ObjectMeta.workspace also carries it on the resource itself.

Target drop

Drop C (implements workspace CRUD and retroactively adds scoping to Drops A and B RPCs)

References

  • ObjectMeta.workspace field: datamodel.proto line 39
  • Request message workspace fields: throughout openshell.proto

Activity

  1. added
    proto-gapProto API surface not yet covered by SDK
    drop-cTarget: Drop C (Provider + Workspace)
    on Jul 29, 2026
  2. rhuss commented on Jul 29, 2026

    @rhuss
    OwnerAuthor

    Implementation Hints

    This issue deserves a full spec (cross-cutting change touching every client, converter, fake, and the public API surface).

    Setup spex (if not already initialized)

    specify --init      # Initialize spex in the repo
    specify --refresh   # Update templates

    Or: /spex:init in Claude Code.

    Recommended workflow

    1. Specify: /spex:spec describing workspace scoping across all RPCs.
    2. Plan: /spex:plan to design the approach.
    3. Tasks: /spex:tasks to break down the work.
    4. Implement: /spex:implement to execute.
    5. Verify: /spex:verify for final checks.

    Key design decisions the spec should address

    • Where does workspace live in the client API? Options:
      • Parameter on each method (e.g., Create(ctx, name, spec, labels, workspace)) -- breaking change
      • CreateOptions struct passed variadically -- non-breaking, extensible
      • Context-based (workspace in context) -- implicit, harder to discover
    • How does all_workspaces interact with ListOptions?
    • Should Get/Delete accept workspace as a parameter or option?
    • Retroactive scoping: update converters for sandbox (Drop A) and exec/file/health (Drop B) RPCs

    Depends on

    Affected files (every sub-client)

    • sandbox_client.go, sandbox.go (SandboxInterface)
    • types/options.go (ListOptions)
    • All future client files (exec, file, health, provider, policy, service, tcp, ssh)
    • All fake implementations
    • All converter functions that build request messages
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    drop-cTarget: Drop C (Provider + Workspace)proto-gapProto API surface not yet covered by SDK

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions