Commit-hash override lacks a human-readable version label

The tarball URL is pinned to a bare commit SHA (1c30d7d7e76a3b0aa120b04dc6a26f5a12dccf67) on the whiskeysockets/libsignal-node fork with no associated semver tag in the URL. This is content-addressed and deterministic, but makes it non-obvious what version of libsignal is actually being used and whether a newer upstream release should be tracked.

Consider adding an inline comment (or a note in CHANGELOG.md / the relevant dependency-audit section) documenting which upstream libsignal release this commit corresponds to, so future maintainers can reason about upgrade windows without having to look up the git SHA manually.

This is a comment left during a code review.
Path: package.json
Line: 417

Comment:
**Commit-hash override lacks a human-readable version label**

The tarball URL is pinned to a bare commit SHA (`1c30d7d7e76a3b0aa120b04dc6a26f5a12dccf67`) on the `whiskeysockets/libsignal-node` fork with no associated semver tag in the URL. This is content-addressed and deterministic, but makes it non-obvious what version of `libsignal` is actually being used and whether a newer upstream release should be tracked.

Consider adding an inline comment (or a note in `CHANGELOG.md` / the relevant dependency-audit section) documenting which upstream `libsignal` release this commit corresponds to, so future maintainers can reason about upgrade windows without having to look up the git SHA manually.

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Top-level overrides vs pnpm.overrides — scope difference to be aware of

The project's package manager is pnpm ("packageManager": "[email protected]"), and all existing overrides are in "pnpm": { "overrides": { … } }. The new libsignal entry is intentionally placed in the top-level "overrides" field so that it is included in the published npm manifest and honoured by npm install -g openclaw.

Worth noting: pnpm 8+ does also respect the top-level "overrides" field, so this entry will be applied for pnpm users as well. However, the split between the two override sections (some in pnpm.overrides, one in top-level overrides) may be confusing to future maintainers. A short comment above the block explaining why it lives here (npm publish compatibility) would make the intent explicit:

"overrides": {
  "libsignal": "https://codeload.github.com/whiskeysockets/libsignal-node/tar.gz/1c30d7d7e76a3b0aa120b04dc6a26f5a12dccf67"
},

This is a comment left during a code review.
Path: package.json
Line: 416-418

Comment:
**Top-level `overrides` vs `pnpm.overrides` — scope difference to be aware of**

The project's package manager is pnpm (`"packageManager": "[email protected]"`), and all existing overrides are in `"pnpm": { "overrides": { … } }`. The new `libsignal` entry is intentionally placed in the top-level `"overrides"` field so that it is included in the published npm manifest and honoured by `npm install -g openclaw`.

Worth noting: pnpm 8+ does also respect the top-level `"overrides"` field, so this entry will be applied for pnpm users as well. However, the split between the two override sections (some in `pnpm.overrides`, one in top-level `overrides`) may be confusing to future maintainers. A short comment above the block explaining *why* it lives here (npm publish compatibility) would make the intent explicit:

```json
"overrides": {
  "libsignal": "https://codeload.github.com/whiskeysockets/libsignal-node/tar.gz/1c30d7d7e76a3b0aa120b04dc6a26f5a12dccf67"
},
```

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Place libsignal override where npm global installs can apply it

This override is added in openclaw’s own manifest, but npm applies overrides only from the active install root, not from dependency manifests. In the target scenario (npm install -g openclaw), openclaw is installed as a dependency of the global root package, so this entry is ignored and @whiskeysockets/baileys can still resolve libsignal via its original SSH/GitHub spec. That means the Windows/global-install path this commit is meant to fix remains broken despite the new test passing.

Useful? React with 👍 / 👎.