fix: make secret redaction one-way and fail closed

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean

[datj9]

What this improves

This PR turns dotmask from reversible response rewriting into one-way, fail-closed request redaction. It addresses the security review findings as follows.

Area	Before	Improved behavior
Response secret oracle	Fake tokens in model responses and tool calls were replaced with real secrets locally. A model could request encoding or exfiltration of the restored value.	Provider responses are forwarded byte-for-byte. All response-unmasking code and tests are removed, so model-controlled output cannot resolve a fake into a real secret.
Request coverage	Only selected fields in parseable JSON POST bodies were scanned. Generic nested properties, textual bodies, GET bodies, encoded output, and malformed JSON could bypass masking.	Every JSON string leaf is traversed recursively. Supported textual bodies and standalone high-entropy values are scanned. Body sanitization applies regardless of HTTP method.
Fail-open behavior	Non-JSON, malformed, compressed, and unsupported bodies could be forwarded without inspection.	Intercepted requests fail closed when JSON is malformed or when the body is compressed, binary, or unsupported.
Fake-token predictability	Fakes used an unkeyed deterministic 32-bit seed and unknown formats leaked a plaintext prefix.	Fakes use a random process-local HMAC key. Unknown formats expose no plaintext prefix, while known structural prefixes and lengths remain compatible.
Secret persistence	Real-to-fake mappings were stored in Keychain, fake identifiers were written to disk, and real values were retained in a process-wide cache.	Mappings are request-local only. The proxy performs no Keychain writes and persists no real-secret mappings.
CA trust scope	The generated CA was installed as a trusted root in the login Keychain.	Claude Code trusts the CA only through NODE_EXTRA_CA_CERTS. Installation removes legacy broad CA trust when found.
Uninstall safety	Cleanup errors were swallowed and certificates, mappings, Keychain items, and logs could remain after a successful-looking uninstall.	Daemon and CA cleanup failures are reported. Uninstall removes identifiable legacy Keychain mappings and deletes certificates, mappings, logs, and managed settings after successful cleanup.
HTTP parser hardening	Request framing had no size bounds and accepted ambiguous or duplicate critical headers.	Requests have 64 KiB header and 16 MiB body limits. Duplicate headers, conflicting Content-Length and Transfer-Encoding, invalid lengths, and unsupported transfer encodings are rejected.
Documentation	The project claimed that secrets never leave the machine and documented transparent restoration.	README, architecture, security policy, CLI text, and package metadata now describe the actual defense-in-depth scope and limitations.

Security impact

The most important change closes the response-side secret oracle. Previously, a model that received a fake token could place it in a shell command such as an encoding or network command. Dotmask would restore the real value before local execution, allowing the model or another endpoint to receive it. Version 2 never materializes real secrets from provider-controlled responses.

The proxy now also blocks intercepted request formats it cannot safely inspect instead of forwarding them unchanged.

Breaking change

This is intentionally versioned as 2.0.0. Model-generated commands containing fake credentials no longer become usable credentials automatically. Tools must obtain real credentials from a trusted local environment at execution time.

Dotmask remains defense in depth rather than a sandbox or DLP boundary. Provider authentication headers still reach the provider, non-allowlisted hosts are passed through, and agents with local filesystem or shell permission must still be constrained with approvals, sandboxing, least-privilege credentials, and network controls.

Verification

• npm test: 95 passing
• TypeScript build: passing
• npm audit: 0 vulnerabilities
• npm pack --dry-run: expected runtime files only
• git diff --check: clean