Kevin CodexandOpenClaude
50d4058861
The npm package moves from the @gitlawb scope to @twigpine. Everything that names the package now uses the new name, and the release workflow can create the new package and close out the old one. Rename - package.json, bun.lock, release-please config, docs, website, VS Code extension and tests use @twigpine/openclaude. - scripts/build.ts takes the baked-in package name from package.json instead of repeating it; scripts/verify-clean-install.ts does the same. One final release under the old name, then nothing - Shipped builds have no working auto-updater (the no-telemetry plugin stubs it out), so people update by re-running the install command. Anyone still typing the old name lands on whatever is latest there. - release.yml publishes this release once more as @gitlawb/openclaude. That build shows a startup notice, and `openclaude update` and `/update` print the same note and stop, saying the package moved and how to switch. - legacy-scope-gate limits this to a single release. It only runs while the old name's latest version is still 0.31.0. - There is no in-place migration. Both packages own the `openclaude` bin, so npm refuses to install one over the other, and a forced install is undone by uninstalling the old package. The docs give the safe order. Tokenless releases (OIDC only) - Both publish steps authenticate through npm trusted publishing and attach provenance; no npm token is used anywhere. npm only attaches a trusted publisher to a package that already exists, so @twigpine/openclaude is created once by hand as an empty 0.0.0 placeholder before its first release. - Publish steps skip a version that is already on the registry, publish the verified dist/ with --ignore-scripts, and report provenance and whether a trusted publisher was used in the run summary (scripts/npm-publish-report.ts). - The legacy-named build is built and install-verified before anything is published. Co-authored-by: OpenClaude <openclaude@gitlawb.com>
2.1 KiB
Security Policy
Supported Versions
Open Claude is currently maintained on the latest main branch and the latest
npm release only.
| Version | Supported |
|---|---|
| Latest release | ✅ |
| Older releases | ❌ |
| Unreleased forks / modified builds | ❌ |
Security fixes are generally released in the next patch version and may also be
landed directly on main before a package release is published.
Reporting a Vulnerability
If you believe you have found a security vulnerability in Open Claude, please report it privately.
Preferred reporting channel:
- GitHub Security Advisories / private vulnerability reporting for this repository
Please include:
- a clear description of the issue
- affected version, commit, or environment
- reproduction steps or a proof of concept
- impact assessment
- any suggested remediation, if available
Please do not open a public issue for an unpatched vulnerability.
Response Process
Our general goals are:
- initial triage acknowledgment within 7 days
- follow-up after validation when we can reproduce the issue
- coordinated disclosure after a fix is available
Severity, exploitability, and maintenance bandwidth may affect timelines.
Disclosure and CVEs
Valid reports may be fixed privately first and disclosed after a patch is available.
If a report is accepted and the issue is significant enough to warrant formal tracking, we may publish a GitHub Security Advisory and request or assign a CVE through the appropriate channel. CVE issuance is not guaranteed for every report.
Scope
This policy applies to:
- the Open Claude source code in this repository
- official release artifacts published from this repository
- the
@twigpine/openclaudenpm package
The package was previously published as @gitlawb/openclaude. That name is no
longer updated and receives no fixes; switch to @twigpine/openclaude.
This policy does not cover:
- third-party model providers, endpoints, or hosted services
- local misconfiguration on the reporter's machine
- vulnerabilities in unofficial forks, mirrors, or downstream repackages