bodicsek

7d905a8394 chore: scope package name to @bodicsek namespace Aligns with codex-app-server-bridge, which was scoped to avoid an unrelated public npm package sharing its unscoped name. This project has no such registry collision, but the README already anticipated scoping once a private registry is available. Update verify-git-package.mjs's hardcoded package-name assumptions to match (manifest name is now scoped; the bin executable name is unchanged). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

il y a 1 jour

06a151f0ca fix: update git-package verifier for scoped package name verify-git-package.mjs hardcoded the unscoped package name for both the manifest name assertion and the node_modules install path, breaking verification after the rename to @bodicsek/codex-app-server-bridge. Split PACKAGE_NAME (scoped, for manifest/path checks) from BIN_NAME (unscoped, for the bin executable, which npm places by bin key not package name). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

il y a 1 jour

5e513ec22f chore: scope package name to avoid npm registry collision Unscoped name codex-app-server-bridge collides with an unrelated public package (w-okada/codex-app-server-bridge on npm), causing `npm outdated -g` to compare this local install against a stranger's releases. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

il y a 1 jour

il y a 3 jours

il y a 1 semaine

0934c5ef81 Fix silent failures in auto-unlock retry and error reporting bitwarden--auto-cmd reused its recursive-pass parameter as both a "have we retried" flag and the retry's pre-computed result. When the vault was still locked after an automatic-unlock retry, every branch fell through and the function returned nil instead of an error tuple, indistinguishable downstream from an empty search result. It now uses a plain boolean flag and always returns a well-formed tuple, reporting "vault is still locked after automatic unlock" when the retry fails. bitwarden--handle-message only printed its error message when PRINT-MESSAGE was set, then always returned nil regardless. Since bitwarden-search (used by the auth-source backend) calls it without PRINT-MESSAGE, every failure was completely silent, so a locked vault or a failed automatic unlock looked identical to "no results found" to any caller. It now signals a user-error unconditionally, which reports cleanly both interactively and via `emacsclient --eval` (as `*ERROR*: ...`), with no changes needed in any calling code. Also fixes two unrelated docstring issues that crashed the byte-compiler outright (not just warned): unescaped single quotes in bitwarden--message, and an over-80-column first line in bitwarden-get-info-by-id that tripped a byte-compiler docstring-reflow bug.

il y a 1 semaine

c3344bbf9c Fix bitwarden-runcmd swallowing unrecognized bw errors as nil bitwarden-runcmd returned nil for any bw CLI error that wasn't "vault is locked" or "more than one result found", which crashed bitwarden--auto-cmd's string-match on nil and, once patched around that, silently misreported the failure as a success. It also discarded stderr entirely, so even a fixed classification would carry no error text. - Preserve unrecognized errors as bitwarden--err-unknown-prefixed output instead of nil. - Classify that prefix in bitwarden--auto-cmd as a real failure. - Merge stderr into stdout in bitwarden--raw-runcmd so the actual bw error message is captured instead of discarded.

il y a 2 semaines