[Feature] Support execution identity for file APIs to enforce per-session filesystem permissions

Reposted from #1842 under my correct GitHub account. The earlier issue was submitted through an unintended connected account. Please use this issue for discussion; could a maintainer close #1842 as a duplicate?

Why do you need it?

Consider a single agent serving multiple concurrent conversation sessions in one sandbox. Each session has a separate workspace and an unprivileged Linux user:

/workspace/session-a/   # owned by session A's user
/workspace/session-b/   # owned by session B's user

With appropriately configured ownership and group permissions, the intended policy is:

• A session can read and write its own workspace.
• It can read other sessions' workspaces, but cannot modify, delete, or rename their files.
• Command execution and file API operations should follow the same Linux filesystem permissions.
• Sessions should be able to run concurrently.

Here, "session" means an application-level conversation; it does not assume use of the isolated-session API. The scope is sessions of a single agent sharing a sandbox, rather than sharing across different agents or providing full tenant isolation.

The command API accepts UID/GID, but the ordinary file APIs do not appear to provide an equivalent execution identity. File owner/group metadata describes ownership, which is different from the identity whose permissions are checked when an operation runs.

From source inspection at 07f0a68dd230:

• Command requests forward UID/GID to the runtime.
• Downloads open files directly in the Execd process.
• Uploads open/create/truncate files directly, then apply ownership/mode metadata.

Consequently, when Execd runs with elevated permissions, configuring session users for commands alone does not make file API operations obey those users' permissions. These observations are based on source review, not an end-to-end reproduction report.

How could it be?

Support an explicit execution identity for filesystem operations, either per request or through a session-bound filesystem client. UID/GID are possible inputs; the exact API and supplementary-group behavior should follow the project's identity model.

Desired semantics:

• Actual filesystem access, including parent-directory traversal and creation, is checked under the selected identity.
• The behavior covers reads, writes/uploads, search/stat, directory creation, deletion, rename, and permission changes.
• Execution identity remains separate from target-file owner/group/mode; metadata changes must not bypass the selected identity's permissions.
• Concurrent operations with different identities cannot affect each other's execution identity.
• If an explicitly requested identity cannot be honored, the operation fails clearly instead of silently using Execd's default identity. SDK/server compatibility should make unsupported behavior detectable.
• Existing callers that omit the option retain their current behavior.

For example, with B's directory and files configured as readable but not writable by A, both a command and a file API request running as A should be able to read B's file, and both should be denied an overwrite or deletion.

A trusted application backend would select the session identity and retain sandbox administration credentials. This request does not propose giving session workloads unrestricted access to choose root or another session's identity.

The implementation is open for discussion. A dedicated filesystem worker running with reduced credentials could be one option; exposing shell commands through the file API is not a requirement.

Other related information

Alternatives considered:

• One sandbox per session: provides a separate boundary but prevents the intended sandbox reuse.
• Perform file operations through commands under the session UID/GID: possible as an application workaround, but requires custom handling for structured errors, binary transfers, and streaming.
• Isolated sessions: may be a better fit if their filesystem proxy can provide the desired permission semantics. Guidance on using or extending that path would be helpful.

Related: #1064 concerns ownership of automatically created parent directories. This request concerns the identity performing the operation, rather than the ownership assigned afterward.

Questions for maintainers:

1. Is consistent execution identity across command and file APIs a supported direction?
2. Should this live in the ordinary filesystem API, the isolated-session API, or another existing abstraction?
3. Is there related work already planned, and would a new OSEP or an extension to an existing OSEP be the preferred next step?

This issue is intended to establish the use case and agree on direction before implementation.