v1.3.2: AI marking, signed SBOM and account controls
v1.3.2 is the current release of the CLI and the MCP server; package manifests and version checks use 1.3.2. It contains everything in v1.3.1 below.
- AI-generated output is marked. JSON from scans and reviews carries ai.ai_generated: true on AI reviews and AI fixes, terminal lines start with "AI-generated review" or "AI-generated fix", and uploads carry the mark, so the dashboard labels them as AI-generated.
- Each release ships a CycloneDX software bill of materials, magdox-sbom.cdx.json, listing the CLI's third-party modules, signed with cosign like the checksums.
- magdox login names the device as "magdox CLI on <os>/<arch>" instead of sending your computer's host name.
- magdox logout revokes its token through the API's new POST endpoint. Older CLIs keep working: their logout still revokes the token.
- The release gate also runs govulncheck on the CLI and the MCP server.
v1.3.2: MCP server
- Tool results stay within 64 KiB so agents can read them. A larger report returns its most severe findings (for magdox_risk, its highest priority ones) and says how many it returned of how many; scan a narrower path to see the rest.
- magdox_check_code accepts tsx, jsx, yml and sh. It refuses an unknown language and asks for a filename or a language instead of checking nothing, and reports findings under the snippet's file name rather than a temporary path.
- Errors say what to change. Argument errors name the argument, the accepted arguments or the repository root; a missing sign-in, vulnerability database or rule set names the magdox command that fixes it; a timeout is reported as a timeout.
- Scan results include each pass's reason, so complete: false says why, for example files skipped.
- Tool descriptions say when to use each tool and what it returns, the schemas declare defaults and the accepted snippet languages, and the server's instructions name the repository root it reads.
- The magdox-secure-coding prompt no longer asks for a vulnerability database path: magdox_audit uses the CLI's own database.
v1.3.2: rules and scanning
- Integer truncation checks (C, C++, C#, Java, Kotlin, Go, Rust) no longer report reading bytes from an array into a wider integer, sizeof, constants, or C# unsigned lengths; an element read from an array of sizes or lengths still is.
- User-controlled regular expression checks (PHP, C#, Kotlin, Scala) look only at the pattern argument: input matched against a fixed pattern is no longer reported.
- Composer: minimum-stability "dev" in a bridge, bundle or plugin manifest is no longer reported; Composer applies it only to the root project.
- Hard-coded credential checks (Go, C#, JavaScript, TypeScript) no longer report secret type names such as kubernetes.io/tls or page paths.
- Kotlin: logging a masked token, a check that one is present, or an error about one is no longer reported.
- Ruby: assigning params to a model is reported in controllers, where params is the request; service objects receive filtered input.
- Dockerfiles: copying a public CA certificate bundle, such as Amazon RDS's, is no longer reported as copying a credential.
- Shell: echo "::add-mask::$SECRET", which hides the value in GitHub Actions logs, is no longer reported as printing it.
- Terraform: an output that lists secret ARNs, IDs or names, rather than secret values, no longer needs sensitive = true.
- A folder the scanner may not read no longer stops the scan: it is listed as not scanned and the result is marked incomplete.
v1.3.2: dashboard changes shipping with it
- The organisation's top role is now called Super Admin; it was called Owner. Every existing Owner is a Super Admin, and nothing else about the role changes.
- Super Admins and admins can remove a member from the organisation. The person's account and their other organisations stay.
- Account deletion runs on a 30-day schedule. A Super Admin deletes a member's account and can restore it within 30 days.
- A Super Admin can delete the whole organisation in Settings, Danger Zone, after typing DELETE and confirming their identity. Everyone is signed out, tokens stop working, renewal and processing pause, and the data is erased after 30 days unless the Super Admin signs in and chooses Reactivate account. The Privacy Policy, section 13.4, lists what is kept.
- When the Terms or Privacy Policy change, the dashboard asks once for the new agreement, and checkout asks you to accept automatic renewal.
- The API accepts only GET and POST requests.
- Sign-in, verification and authenticator codes are entered one digit per box; pasting the whole code fills every box.
- Opening MAGDOX from your identity provider's app portal shows a Continue page on MAGDOX first, and the sign-in starts only when you choose Continue, so another website cannot start one for you.
- Only a Super Admin can connect or replace the identity provider and change the single sign-on policy, after confirming their identity again. Admins still verify email domains and see the settings.
- SCIM 2.0 provisioning: a Super Admin creates a SCIM token under Settings, Single sign-on. Your identity provider can then invite, update, deactivate and remove members on your verified domains; a deactivated member loses access to the organisation, their sessions and tokens there, and their link to your identity provider.
- Sign-in protection without a CAPTCHA, and the sign-up page no longer shows one. Repeated failed sign-ins, codes or password resets lock further attempts for 30 minutes, and the lock clears by itself. Networks you have signed in from in the last 30 days are not locked by other people's attempts.
- After 100 wrong second-factor codes in a row, codes stop working for 30 minutes at a time. A recovery code still signs you in, and a Super Admin can unlock the account from Members.
- Locks, early unlocks and recovery-code sign-ins appear in the audit log of each organisation the account belongs to, and in no other.
- Approving a CLI sign-in shows where and when the request was made.
- Agreement to the Terms, the Privacy Policy and the age confirmation counts only when a Google or GitHub sign-in starts on MAGDOX's own sign-up page.
- Google sign-in needs an email address that Google has verified.
- Organisation names cannot contain web links or email addresses.
v1.3.2: upgrading
Homebrew and npm keep an installed 1.3.1 until you upgrade; v1.3.2 is a new version number, so both pick it up. Run magdox version afterwards.
brew upgrade magdox/tap/magdox
npm install -g '@magdox/cli@1.3.2' '@magdox/mcp@1.3.2'
magdox versionv1.3.1: offline licences in one step
v1.3.1 contains everything in v1.3 below, plus a simpler offline licence exchange for machines that cannot reach MAGDOX.
- magdox license request prints a single line (beginning mgdx_req1.). An owner or admin pastes it under Settings > Offline licences in the dashboard. --json still prints the previous request form.
- The dashboard returns one licence file holding the licence and the encrypted rules. magdox license import <file> installs it, and it works only on the machine that printed the code. --package and --archive still import the two-file form.
- Offline access still follows the plan: up to 7 days on Team, 30 on Business and 90 on Enterprise, never past what is paid for. Enterprise owners and admins issue air-gapped licences that end with the organisation's contract.
- The MCP tools are unchanged, and v1.3 private components work with the 1.3.1 launcher.
v1.3.1: upgrading
Homebrew and npm keep an installed 1.3.0 until you upgrade; v1.3.1 is a new version number, so both pick it up. Run magdox version afterwards.
Security fixes are released only in the latest version, and older releases are not supported. Releases are published at https://github.com/Magdox/magdox-cli/releases and on this page.
brew upgrade magdox/tap/magdox
npm install -g '@magdox/cli@1.3.1' '@magdox/mcp@1.3.1'
magdox versionv1.3: CLI and MCP together
The CLI and the MCP server are both v1.3; package manifests and version checks use 1.3.0. The package names remain @magdox/cli and @magdox/mcp, and distribution is unchanged from v1.2: the public launcher signs you in and installs the authorised private engine, MCP server and plugin bundle. Run magdox version after upgrading and magdox install to fetch the matching private components.
Nothing changes for a scan that uses none of the new options: ordinary output, exit codes and severity gates behave as in v1.2.
v1.3: changes to review before upgrading
| Area | Change | Important boundary |
|---|---|---|
| Local risk assessment | scan --risk adds an explained P1 to P4 priority to each finding from severity, cached threat intelligence, a declared context file (--risk-context) and optional local decisions. risk assess re-assesses a saved scan offline; --risk-baseline compares two scans as new, persistent and no longer observed | Severity and confidence never change. Local decisions are not organisation approvals, are never uploaded and never remove findings. No longer observed is not verified remediation. |
| Risk reports and gates | Compact text, complete JSON, CSV and XML, and a filterable offline HTML risk report; --fail-priority p1 adds a priority gate next to --fail-on | Gates are additive and local exceptions cannot waive them. Exit 4 still takes precedence over incomplete exit 3. New report files are owner-only and refuse to overwrite. |
| Repository naming | --repository replaces --project for scan, aibom and payload previews, and upload results link to the repository page in the dashboard | --project still works, so existing scripts and CI jobs need no change. |
| Offline access | Offline use follows your plan: up to 7 days on Team, 30 on Business and 90 on Enterprise, never past what is paid for. Online, a licence close to the end of its lease renews in the background; a lapsed device licence renews itself without a new sign-in | Revoked or denied access still stops the CLI, and moving the clock backwards is still refused. |
| Contract-bound licences | Enterprise owners and admins can issue air-gapped licences from the dashboard that end with the organisation's contract. v1.3 is required to accept them | An offline licence never renews and is refused after its end date. |
| Licence messages | Clear instructions when your CLI licence is bound to another computer or your organisation has no active plan | Messages are fixed text in the build; server wording is never printed. |
| Large uploads | Uploads larger than 4 MB are staged through a one-time HTTPS storage address bound to the upload's size and SHA-256 checksum | Upload content, permissions and the --show-payload preview are unchanged; the preview is still not the exact upload body. |
| Analysis | C and C++ buffer accesses that constants prove out of bounds; input-chosen sizes for allocation, reservation and sleep tracked through numeric conversions until an upper bound applies (CWE-789); per-file query matching is bounded | Results depend on the signed rule bundle installed. The source rule inventory is not a detection-rate benchmark. |
| Dependencies | Go builds read go.mod and go.sum with module graph pruning and replacements, and flag go.work workspaces; Python requirements follow -r includes inside the scan root; .NET project files are read | Static reading only. Unpinned ranges and versions a static read cannot select are reported as unresolved or uncertain, never guessed. |
| HTML report | The offline HTML report renders correctly in release builds, and a missing report field now fails instead of producing an incomplete page | Reports can contain source excerpts. Keep them in access-controlled storage. |
| Windows | The engine and everything it starts run inside a Windows job object, so stopping magdox or the MCP server stops them too | Automatic hooks remain POSIX-only; Windows hooks are unsupported. |
v1.3: MCP server
| Area | Change | Important boundary |
|---|---|---|
| New tools | magdox_cbom inventories cryptographic algorithms, certificates and keystore locations; magdox_risk assesses a saved scan with optional context, decisions and baseline files | magdox_risk is read-only: it cannot write files, fetch rules, upload or override licence checks. |
| Secrets | The secrets tool returns counts, severity totals and coverage status only | Previews, digests, locations and raw values are never forwarded to the assistant. |
| Root confinement | Every input path must be an existing regular file inside a configured root; traversal and symbolic links are rejected | A supplied --root must be a canonical absolute path. Product access is still checked by the CLI. |
| Stricter results | A clean result needs findings, positive rule and file coverage and completed scan passes; aibom and cbom matched lines are omitted unless include_code is requested | Missing evidence or contradictory coverage is reported as incomplete, never as clean. |
| Protocol | Duplicate or ambiguous JSON properties and noncanonical field names are rejected before a tool runs | Clients that relied on loose parsing must send exact field names. |
v1.3: upgrading from v1.2
- Upgrade the public launcher to 1.3.0, then run magdox install so the engine, MCP server and plugin bundle match it. A v1.2 engine cannot accept contract-bound licences.
- Scripts and CI jobs that pass --project keep working; switch to --repository when convenient.
- Consumers of scan --risk --format json receive the ordinary scan document plus a risk section; without --risk the JSON is unchanged. Use risk assess --format json to share a risk report without source data.
- Team and governed approvals, organisation campaigns and multi-branch coverage policies stay in the dashboard and API; local risk files cannot grant that authority.
Earlier release: v1.2
The notes below describe v1.2 and still apply to v1.3 unless a v1.3 change above replaces them.
v1.2: two public packages, one authenticated workflow
The package names remain @magdox/cli and @magdox/mcp. There is no new public plugin package. The lightweight launcher is public; the scanning engine, MCP server and plugin bundle are private downloads requiring CLI-capable product access. The plugin is delivered with the MCP integration installation, not as an unauthenticated standalone download.
Settings > Developer tools provides setup guidance and authenticated release availability. It is locked for accounts without CLI permission. The browser cannot confirm that software is installed on your computer: use local diagnostics and test the integration in your selected host.
v1.2: changes to review before upgrading
| Area | Change | Important boundary |
|---|---|---|
| Terminal | Progress on stderr, severity-first summaries, bounded finding groups and compact upload results; --details expands findings | --quiet hides progress, not findings. Machine-readable reports use stdout or --out. |
| HTML report | Offline severity tiles, engine charts, searchable filters, grouping and pagination | Reports can contain source excerpts. Keep them in access-controlled storage. |
| Exit status | 1: failure; 3: incomplete analysis; 4: a severity or policy gate failed | A gate failure takes precedence over incomplete coverage. A partial scan is not a clean result. |
| Privacy | Customer reports, assistant feedback and preview output omit private rule metadata | JSON, SARIF, CSV and XML consumers must be checked: redaction changes the old output contract. |
| MCP and plugin | Authenticated MCP installation also provisions the signed integration bundle | Host-specific activation remains necessary. Generated configuration is not an end-to-end validation. |
| Account settings | Authenticator verification for email changes, with a password fallback for accounts without an authenticator | Email ownership must still be confirmed. Identity-provider failures must not skip verification. |
| Scan email | Every scan, new findings at a selected severity, daily digest or off | Settings are per user and organisation. A daily digest combines repositories within that organisation. |
| Inventories | A completed inventory can be retained even when another scan pass is incomplete | Finding closure still requires comparable evidence; a partial pass must not make findings appear fixed. |
v1.2: compatibility and validation
For setup, use Install the CLI and AI integrations. Only the Claude Code hook integration has been tested end to end in the recorded integration review; other host setup files remain experimental until validated in that host. Automatic hooks are POSIX-only; Windows hooks are unsupported. MCP client setup and a successful local doctor check are not evidence that every assistant feature works.
The source rule inventory is not the deployed bundle inventory or a detection-rate benchmark. Consult Coverage and your installed rule status. Runtime controls, SSO policies, race conditions and account-wide lifecycle guarantees still need application testing.
Earlier release: v1.1
v1.1 (package version 1.1.0, released 25 September 2026) updated the CLI scanning engine. The MCP server stayed at v1.0.
- Cross-file taint analysis: data flows are followed across files and branches, guards and early returns are honoured, and reports show each cross-file step. A re-scan refreshes only the files a change reaches.
- 28 more provider secret detectors, covering keys and tokens for cloud, source-control, payment, messaging, package-registry and AI services.
- Dependencies: lockfiles for eight more ecosystems (Yarn, pnpm and Bun; Poetry, uv and Pipfile; Gradle lockfiles; NuGet packages.lock.json), native Maven and RubyGems version comparison, fixed Swift and case-insensitive advisory matching, and an inventory that continues past an unparsable manifest.
- Inventories: the CBOM lists keystores, the AI inventory catalogue is larger and matches whole words, and malicious-package checks run on every inventoried component.
- Uploads label each finding's surface by the language of the rule that found it.
Earlier release: v1.0
v1.0 (package version 1.0.0, released 24 September 2026) was the first stable release of the CLI and the MCP server.
- One scanner for source code, infrastructure definitions, dependencies (from the platform's vulnerability database) and secrets, with SBOM, CBOM, AI inventory, SARIF and VEX output and text, JSON, CSV, XML and HTML reports.
- Analysis runs on your machine. Findings and inventories upload only with --upload, and source snippets only with explicit consent.
- Installs through Homebrew (magdox/tap/magdox), npm (@magdox/cli) and the magdox.io install script, with SHA-256 checksums signed through Sigstore.
- Offline use: magdox scan --offline runs on cached rules and the cached vulnerability database, and magdox vulndb export carries the database to an air-gapped machine.
- Optional AI review with your own model provider: advisory verdicts per finding and fixes the engine re-checks; nothing is sent until you approve the project.
- The MCP server (@magdox/mcp 1.0.0) connects desktop and coding assistants to local scans over stdio.