fix(sdk): support sending stdin through the PTY command handle

[mishushakov]

Summary

Calling send_stdin/sendStdin on the handle returned by pty.create()/pty.connect() previously raised "Sending stdin is not supported for this command handle" because the PTY path never wired up the handle's stdin callback — unlike regular command handles. This wires it up across the JS and Python (sync + async) SDKs, makes PTY input methods also accept str (encoded as UTF-8), and in JS adds pty.sendStdin() as the canonical method (mirroring commands.sendStdin()) with pty.sendInput() kept as a deprecated alias.

Usage

terminal = sandbox.pty.create(size=PtySize(rows=24, cols=80))
terminal.send_stdin(b"whoami\n")   # now works on the handle
terminal.send_stdin("exit\n")       # str is accepted too
terminal.wait(on_pty=lambda data: print(data.decode(), end=""))

const terminal = await sandbox.pty.create({ cols: 80, rows: 24, onData: () => {} })
await terminal.sendStdin('whoami\n')        // on the handle
await sandbox.pty.sendStdin(terminal.pid, 'exit\n')  // new canonical module method

Tests

Added handle-level and str-input tests for sync/async Python and JS (plus a JS test for the deprecated sendInput alias); all pass against a live sandbox.

[changeset-bot]

🦋 Changeset detected

Latest commit: 4de3c60

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@e2b/python-sdk	Patch
@e2b/cli	Patch
e2b	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cursor]

PR Summary

Low Risk
Additive SDK API fix with backward-compatible aliases; no auth or data-model changes.

Overview
pty.create() / pty.connect() handles used to error on send_stdin / sendStdin because the PTY path did not pass a stdin callback into CommandHandle. This PR wires that callback in the JS and Python (sync and async) SDKs so handle stdin matches regular command handles.

PTY module send_stdin / sendStdin now accept str as well as bytes, encoded as UTF-8. In JS, sandbox.pty.sendStdin() is the canonical PID-based API (aligned with commands.sendStdin()); sendInput() remains as a deprecated alias. The CLI switches internal calls to sendStdin() with no intended behavior change. Tests cover handle-level stdin, string input, and the JS deprecated alias.

^{Reviewed by Cursor Bugbot for commit 4de3c60. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Package Artifacts

Built from 6b7e00b. Download artifacts from this workflow run.

JS SDK (e2b@2.36.2-mishushakov-pty-send-stdin-error.0):

npm install ./e2b-2.36.2-mishushakov-pty-send-stdin-error.0.tgz

CLI (@e2b/cli@2.16.1-mishushakov-pty-send-stdin-error.0):

npm install ./e2b-cli-2.16.1-mishushakov-pty-send-stdin-error.0.tgz

Python SDK (e2b==2.35.0+mishushakov.pty.send.stdin.error):

pip install ./e2b-2.35.0+mishushakov.pty.send.stdin.error-py3-none-any.whl

[claude]

LGTM — small, well-tested fix that mirrors the existing pattern for regular command handles.

Extended reasoning...

Overview

This PR fixes a real bug where calling send_stdin/sendStdin on the handle returned by pty.create()/pty.connect() raised "Sending stdin is not supported for this command handle." The PTY paths in the JS, Python sync, and Python async SDKs now pass a handle_send_stdin callback to CommandHandle/AsyncCommandHandle, mirroring the wiring already used by commands.start()/commands.connect(). It also broadens PTY input methods to accept str (encoded as UTF-8), and in JS adds pty.sendStdin() as the canonical name with pty.sendInput() kept as a deprecated alias.

Security risks

None. This is an SDK convenience fix that routes user-supplied input through an existing, authenticated gRPC method. No auth, crypto, or permission surfaces are touched, and the underlying wire format is unchanged — str is just UTF-8 encoded client-side before reaching the same ProcessInput.pty bytes field.

Level of scrutiny

Low. The change is mechanical: it slots a callback into a constructor position that the sibling commands module already populates, and the JS CommandHandle constructor's parameter at that index (handleSendStdin) matches the new lambda's signature. Both Python CommandHandle classes accept handle_send_stdin as a keyword arg and already had the runtime check that raises the prior error message. Tests were added for all three SDKs (JS, Python sync, Python async) covering both the module-level method and the new handle-level method, including str input.

Other factors

The one bug-hunter finding (the CLI at packages/cli/src/terminal.ts:29 still calls the freshly-deprecated sendInput) is a true nit — the alias delegates to sendStdin so behavior is identical; only an IDE deprecation strikethrough is introduced. It does not block approval. The closure captures pid into a local variable before passing it to the lambdas, which also incidentally fixes a latent staleness pattern in the prior lambda: self.kill(start_event.event.start.pid) form.

[linear-code]

SDK-221

[ValentaTomas]

My reluctance here is that we don't feed the input to the process stdin, so I didn't want to name it stdin. Also the output is not called stdout (the same case), so the symmetry is already broken.

Might make sense to have both for compatibility, but does not feel very clean then.