Skip to content

Command timeout does not bound total duration while output continues #113

Closed

Description

@anycodes

Reproduction

Fresh public agent-sandbox-client[all]==0.4.0a1, Express base sandbox. Run a Python process that prints and flushes every 0.3 seconds for 20 iterations with await sandbox.commands.run(command, timeout=1).

Expected: typed CommandTimeoutError after approximately the execution limit, with the owned process stopped. Actual: successful exit after 6.46 seconds, all 20 output ticks, no timeout. The test sandbox was cleaned up.

Cause

The provider process adapter converts HTTP read inactivity timeouts but does not enforce a total execution deadline. Periodic output resets HTTP inactivity waiting.

Acceptance

  • Enforce the existing documented command execution deadline with and without ongoing output.
  • Retain typed errors, close the stream and attempt to stop only the owned timed-out PID.
  • Add regressions for continuing output, silence, successful short commands and cleanup.
  • Reproduce on the real backend, then publish the minimal alpha patch and verify the public installation.

Discovered during the documentation/example rerun; related #111. No credentials or resource identities are included.

Activity

  1. anycodes commented on Oct 25, 2026

    @anycodes
    ContributorAuthor

    Resolved by merged PR #112 and the immutable public client/server v0.4.0a2 release. The publication workflow's second attempt succeeded; the initial index-propagation failure remains preserved separately under #114.

    Fresh official PyPI a2 rerun: a one-second silent command raised typed CommandTimeoutError in 1.353 s; continuously printing command did so in 1.159 s. Each exact owned PID was absent from process listing after the timeout, a subsequent command succeeded, and an independent connection confirmed the owned sandbox no longer existed. These are actual cloud observations, not protocol mocks. New point-in-time documentation/evidence is included in #117; the unrelated browser example cold-install failure remains tracked as #115 and broad example Issue #111 stays open.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions