Conversation
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis PR refactors documentation to reframe AgentRemote as a bridge layer, adds CLI-focused install/release/CI artifacts, introduces OpenClaw gateway discovery and provisioning (mDNS/avahi support and prefilled login flows), updates many bridge READMEs/specs to simplified modes, and adds Docker/homebrew packaging scripts and workflows. Changes
Sequence Diagram(s)sequenceDiagram
participant CLI as AgentRemote CLI
participant Prov as Provisioning API (./tools/bridges)
participant Disc as Discovery Runner (dns-sd / avahi)
participant GW as OpenClaw Gateway
participant OC as OpenClawConnector
CLI->>Prov: GET /v1/discovery/gateways?wide_area=...
Prov->>Disc: run discovery (timeout)
Disc-->>Prov: discovered gateway metadata
Prov->>OC: registerLoginPrefill(user, url, label)
OC-->>Prov: flowID + expiry
Prov-->>CLI: discovery response with prefill flow
CLI->>CLI: user selects prefilled login (flowID)
CLI->>OC: CreateLogin using prefill flowID
OC->>GW: connect/login using gateway URL/token
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ❌ 3❌ Failed checks (1 warning, 2 inconclusive)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/bridge-orchestrator.md`:
- Around line 15-17: Replace the insecure example that passes a bearer token on
the command line (the `./tools/bridges auth set-token --token ... --env prod`
usage) with a safer pattern: show using an environment variable (e.g., export
BRIDGE_TOKEN=...), a prompt/interactive flow (e.g., `./tools/bridges auth
set-token` which prompts for the token), or reading from a protected file (e.g.,
`./tools/bridges auth set-token --file /path/to/secret`), and make one of those
the primary example while keeping a note about avoiding `--token` on the command
line; update the docs lines that mention `./tools/bridges auth set-token
--token` and any help text recommending `--token` to instead reference
`BRIDGE_TOKEN`, interactive prompt, or `--file`.
In `@docs/msc/com.beeper.mscXXXX-streaming.md`:
- Around line 61-63: The doc currently says "`seq` is strictly positive and
monotonic per turn" which is ambiguous; update the wording to explicitly require
that `seq` is strictly increasing (i.e., each subsequent `seq` value for the
same `turn_id` must be greater than the previous one), and keep the other
constraints (`turn_id` is required, `part` is required) unchanged so clients
know to reject non-increasing or equal `seq` values.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 02f2b442-f608-4831-a6a7-dc396781df8c
📒 Files selected for processing (9)
README.mdbridges/codex/README.mdbridges/openclaw/README.mdbridges/opencode/README.mddocs/bridge-orchestrator.mddocs/matrix-ai-matrix-spec-v1.mddocs/msc/com.beeper.mscXXXX-commands.mddocs/msc/com.beeper.mscXXXX-ephemeral.mddocs/msc/com.beeper.mscXXXX-streaming.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Lint
- GitHub Check: build-docker
- GitHub Check: build-docker
🔇 Additional comments (10)
bridges/opencode/README.md (1)
1-39: Clear and consistent bridge-mode documentation.The mode split (
remotevsmanaged) and login prompts are easy to follow, and the run instructions are still straightforward.bridges/codex/README.md (1)
1-35: Good cleanup and alignment with bridge docs.The runtime framing, login modes, and
CODEX_HOMEbehavior are documented clearly and match the simplified doc style.docs/msc/com.beeper.mscXXXX-ephemeral.md (1)
3-9: Status note is concise and unambiguous.This clearly communicates that
com.beeper.ephemeralis currently out of scope and points readers to the active streaming model.bridges/openclaw/README.md (1)
1-31: Solid bridge-focused rewrite.The transport/login flow is clearer now, especially the device-pairing note and request ID behavior.
README.md (1)
3-50: Top-level README is much clearer and easier to scan.The bridge table, quick start, and SDK pointers provide a strong entry path without overloading details.
docs/msc/com.beeper.mscXXXX-commands.md (1)
1-34: Compact and practical command-profile spec.The structured-vs-plaintext precedence and built-in command table are clear for implementers and clients.
docs/matrix-ai-matrix-spec-v1.md (4)
1-3: Clear scope and status framing.The intro cleanly sets experimental status and narrows the doc to emitted transport behavior, which matches the PR’s documentation re-scope.
Also applies to: 5-15
16-31: Streaming and persistence semantics are well specified.The canonical
m.room.message+com.beeper.aishape,com.beeper.llmdelta envelope, and finalization authority are concise and internally consistent.Also applies to: 33-70
71-87: Compaction/metadata sections are concise and implementation-oriented.The reduced compaction field list and “Extra keys/Notes” guidance are clear and appropriately scoped for a transport spec.
Also applies to: 91-106
89-89: The relative link to./msc/com.beeper.mscXXXX-commands.mdis valid and the target file exists with the expected content aboutorg.matrix.msc4391.command_description. No issues detected.
| - `./tools/bridges login --env prod` | ||
| - `./tools/bridges auth set-token --token syt_... --env prod` | ||
| - `./tools/bridges whoami` |
There was a problem hiding this comment.
Avoid documenting bearer tokens in command-line arguments.
Passing tokens via --token ... encourages leaking secrets through shell history and command inspection. Please document a safer input path (prompt/env/file) as the primary example.
Suggested doc tweak
- `./tools/bridges login --env prod`
-- `./tools/bridges auth set-token --token syt_... --env prod`
+- `./tools/bridges auth set-token --env prod` # enter token via prompt (preferred)
- `./tools/bridges whoami`🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/bridge-orchestrator.md` around lines 15 - 17, Replace the insecure
example that passes a bearer token on the command line (the `./tools/bridges
auth set-token --token ... --env prod` usage) with a safer pattern: show using
an environment variable (e.g., export BRIDGE_TOKEN=...), a prompt/interactive
flow (e.g., `./tools/bridges auth set-token` which prompts for the token), or
reading from a protected file (e.g., `./tools/bridges auth set-token --file
/path/to/secret`), and make one of those the primary example while keeping a
note about avoiding `--token` on the command line; update the docs lines that
mention `./tools/bridges auth set-token --token` and any help text recommending
`--token` to instead reference `BRIDGE_TOKEN`, interactive prompt, or `--file`.
| - `turn_id` is required | ||
| - `seq` is strictly positive and monotonic per turn | ||
| - `part` is required |
There was a problem hiding this comment.
Clarify seq ordering to avoid ambiguous client behavior.
“Monotonic” can be read as non-decreasing; for stream replay/ordering safety, this should explicitly require strictly increasing sequence numbers.
Suggested wording fix
-- `seq` is strictly positive and monotonic per turn
+- `seq` is strictly increasing per turn (1, 2, 3, ...)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - `turn_id` is required | |
| - `seq` is strictly positive and monotonic per turn | |
| - `part` is required | |
| - `turn_id` is required | |
| - `seq` is strictly increasing per turn (1, 2, 3, ...) | |
| - `part` is required |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/msc/com.beeper.mscXXXX-streaming.md` around lines 61 - 63, The doc
currently says "`seq` is strictly positive and monotonic per turn" which is
ambiguous; update the wording to explicitly require that `seq` is strictly
increasing (i.e., each subsequent `seq` value for the same `turn_id` must be
greater than the previous one), and keep the other constraints (`turn_id` is
required, `part` is required) unchanged so clients know to reject non-increasing
or equal `seq` values.
Introduce a gatewayClientIdentity and resolver helpers to derive client ID, version, platform, device family, instance ID and user-agent. Wire the identity into websocket dial headers, connect params, HTTP requests, and the signed device payload (so visible client metadata is covered by the device signature). Change default client constants (ID -> "beeper-bridge", mode -> "ui", display name -> "Beeper") and remove sessions.patch from preferred gateway methods. Remove legacy OpenClaw slash-command parsing and session-patch handling from manager; update tests to verify slash commands (/model, /stop) pass through, to check presence of instanceId/userAgent, and to assert the device signature covers visible client metadata.
Update maunium.net/go/mautrix to pseudo-version v0.26.5-0.20260323230949-0eafa0ba2e5d in go.mod and add the corresponding checksums to go.sum. This brings in the newer upstream commit for mautrix.
1 participant
No description provided.