Repository navigation
🌳 feat: Isolate Attached Workspaces by Conversation - #16107
Conversation
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Something went wrong. Try again later by commenting “@codex review”. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6fe50eba60
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ...(attached | ||
| ? { | ||
| workspaceId: context.codeWorkspace?.workspaceId, | ||
| workspaceInstanceId: context.codeWorkspace?.workspaceInstanceId, |
There was a problem hiding this comment.
Pin the Agents release before forwarding workspace instances
When programmatic tool calling is enabled for an attached workspace advertising git_worktree, this only passes workspaceInstanceId as an untyped extra option while package-lock.json still pins @librechat/agents 3.8.7, whose declared PTC options do not include or forward that field. Consequently PTC commands continue executing in the shared base workspace while the native file and Bash tools use the conversation worktree, defeating the isolation guarantee and potentially exposing changes across conversations. Pin the Agents release that implements workspace-instance forwarding before enabling this path.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Valid blocker. Workspace-instance forwarding is implemented by companion Agents PR LibreChat-AI/agents#548, but that PR is still open and no package release containing it exists yet. This LibreChat PR remains draft and will not be marked ready until that release is pinned in package.json/package-lock.json. Merge commit 471a652 only reconciles the branch with current dev and intentionally does not pretend 3.8.7 supports this option.
…on-workspaces # Conflicts: # packages/api/src/agents/execution.ts # packages/api/src/code/capabilities.ts # packages/api/src/code/command.ts
|
Codex Review: Didn't find any major issues. Nice work! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Security review correctly identified that the currently locked Agents 3.8.7 does not forward workspaceInstanceId through PTC. I restored this PR to draft. Do not merge or deploy this integration until LibreChat-AI/agents#548 is merged and released, the dependency and lockfile are updated here, and ordinary + programmatic calls are verified against the same instance. Green CI with the old SDK is not evidence that this boundary works. Code Interpreter findings are addressed separately in #239 at f255141135e7636c106d506f47cf67b0e4e0dc1f. |
Summary
git_worktreesupportStack dependencies
@librechat/agents3.8.8Focused verification
workspace_instance_idused by ordinary workspace toolsSecurity properties