feat: add permissioned Codex session access - #1164
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. |
|
Codex review: needs real behavior proof before merge. Reviewed August 15, 2026, 8:35 AM ET / 12:35 UTC. ClawSweeper reviewWhat this changesThis PR adds a tray-controlled permission that exposes three bounded, read-only Codex App Server catalog and transcript commands through the Windows node’s Gateway and local MCP transports. Merge readiness⛔ Blocked until stronger real behavior proof is added - 10 items remain Keep open for maintainer direction and a rebase. The branch adds a real privacy-sensitive capability, but its current head conflicts with and removes the current-main settings-change seam, and its proof does not include inspectable command output. Priority: P2 Review scores
Verification
How this fits togetherTray settings control which Windows-node capabilities are available. The node passes permitted catalog requests to a local Codex App Server process and returns bounded results to a paired Gateway or local MCP client. flowchart LR
A[Tray settings] --> B[Capability registry]
B --> C[Codex catalog bridge]
D[Local Codex App Server] --> C
C --> E[Paired Gateway]
C --> F[Local MCP client]
E --> G[Gateway command trust]
Decision needed
Why: The patch adds new persistent permission and capability surface for private transcript access; source review cannot determine whether that long-term integration belongs in core or an extension boundary. Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Rebase onto current main, integrate the permission refresh as a SettingsChangeCoordinator effect, clearly surface command-trust reapproval, and land only after maintainers sponsor the direct Codex App Server contract. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR proposes a new capability rather than reporting broken existing behavior. Its stated runtime result is not accompanied by inspectable command output or an artifact. Is this the best way to solve the issue? No. The proposed feature may be viable, but this branch must first preserve current-main settings ownership and receive maintainer confirmation that core should own the external Codex App Server contract. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against fc9add75eda7. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
What Problem This Solves
The Windows node cannot currently provide an explicitly authorized, bounded Codex session catalog to a paired OpenClaw Gateway. Operators either lack the metadata needed for private reconciliation or would need a broader, less auditable access path.
Why This Change Was Made
This adds a user-controlled Codex session-access permission, trusted standalone-executable discovery, a hardened App Server lifecycle, and bounded current/history/archived catalog commands. Catalog projections, request accounting, authorization, cancellation, path discovery, and 60-second catalog-specific timeouts are validated while existing command timeouts remain unchanged.
User Impact
Windows users can explicitly allow a paired Gateway to enumerate safe Codex session metadata for Workboard reconciliation, revoke that access, and retain clear permission boundaries without exposing transcript bodies by default.
Evidence
./build.ps1passed for Shared, CLI, WinNode CLI, Setup Engine, and WinUI.Change Type
Scope
winnodeValidation
./build.ps1— passed.dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore— 3,726 passed, 32 skipped, 0 failed.dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore— 2,291 passed, 0 skipped, 0 failed.Real Behavior Proof
e29b7be53c970ad048d66b9f6836b94a7ed417ea.Security Impact
Yes, explain the risk and mitigation: access is disabled until explicitly granted, bound to the paired Gateway lifecycle, revoked on permission changes, limited to allowlisted catalog methods, projected to bounded metadata, and backed by traversal/reparse/executable-trust and request-lifecycle tests.Compatibility and Migration
Review Conversations