docs(sdk): rename team to project in snapshot docstrings

[mishushakov]

Renames team → project terminology in the JS and Python SDK snapshot docstrings: the list_snapshots/snapshot list name filter example now reads "my-project/my-snapshot", and SnapshotInfo.names is documented as "including project slug and tag (e.g. project-slug/my-snapshot:v2)".

Documentation-only — no exported names, runtime behavior, or wire protocol change; generated API clients and spec/openapi.yml are intentionally untouched until the backend exposes project-named endpoints. Includes a patch changeset for e2b and @e2b/python-sdk.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: e512752

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

This PR includes changesets to release 2 packages

Name	Type
e2b	Patch
@e2b/python-sdk	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
Comment-only SDK changes with no runtime or API behavior change; main risk is misleading docs if production names are still team-scoped.

Overview
Hand-written JS (SnapshotListOpts, SnapshotInfo) and Python snapshot docs now say project (my-project/my-snapshot, project-slug/...) instead of team, including list_snapshots docstrings on sync/async Sandbox, plus a patch changeset for e2b and @e2b/python-sdk.

Generated API client text is unchanged (schema.gen.ts, Python get_snapshots.py, and related models still document my-team/my-snapshot and team namespace), so SDK-facing docs and OpenAPI-generated docs disagree.

If the API still returns team-scoped names on the wire, the new examples may not match real name filters or names values until the backend/OpenAPI spec is updated.

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

[github-actions]

Package Artifacts

Built from d3d39a9. Download artifacts from this workflow run.

JS SDK (e2b@2.35.1-team-to-project-sdk-rename.0):

npm install ./e2b-2.35.1-team-to-project-sdk-rename.0.tgz

CLI (@e2b/cli@2.13.4-team-to-project-sdk-rename.0):

npm install ./e2b-cli-2.13.4-team-to-project-sdk-rename.0.tgz

Python SDK (e2b==2.34.0+team.to.project.sdk.rename):

pip install ./e2b-2.34.0+team.to.project.sdk.rename-py3-none-any.whl

[claude]

This is a small, mechanical docstring change, but the new "project" terminology isn't backed by the actual API yet — the generated client code and spec/openapi.yml still document team-slug/my-team naming, and I don't see a related backend change in history. Worth a quick human check that this rename is actually planned/coordinated before merging docs that describe behavior the API doesn't yet implement.

Extended reasoning...

Overview

This PR only touches docstrings/comments in the hand-written JS and Python SDK files (sandboxApi.ts, sandbox_api.py, sandbox_async/main.py, sandbox_sync/main.py) plus a changeset. It replaces "team" terminology with "project" in snapshot-related examples (e.g. my-team/my-snapshot → my-project/my-snapshot, team-slug → project-slug). No exported symbols, function signatures, or runtime logic change.

Security risks

None — this is a comment-only change with no effect on request/response handling, auth, or data flow.

Level of scrutiny

Normally a pure docstring change like this would be a clear auto-approve. However, I verified (matching what Cursor's bot already flagged) that the generated API client code (schema.gen.ts, snapshot_info.py) and spec/openapi.yml still consistently use "team"/team-slug terminology for the exact same fields this PR is renaming. I also checked git history for any related backend/spec rename and found none. So the hand-written docstrings now describe a naming scheme (project-slug/...) that doesn't match what the API actually returns today, which could mislead SDK users about the real format of SnapshotInfo.names or the name filter.

Other factors

The PR description acknowledges the generated client and OpenAPI spec were left untouched "until the backend exposes project-named endpoints," suggesting this may be intentionally ahead of a planned backend change — but there's no visible evidence in this repo confirming that plan is confirmed/scheduled. Given the risk of shipping documentation that contradicts actual current behavior, a human should confirm the terminology change is coordinated with the backend before merging.