Release: version packages#134
Conversation
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved GitHub Actions PR — 03aa00c0
This PR was opened by trusted GitHub Actions automation.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
tangletools · auto-approval · reason: github_actions_author · 2026-07-14T11:34:25Z
tangletools
left a comment
There was a problem hiding this comment.
🟢 Value Audit — sound
| Verdict | sound |
| Concerns | 0 (none) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 74.9s (2 bridge agents) |
| Total | 74.9s |
💰 Value — sound
Automated Changesets release PR bumping version to 0.35.4 to publish the already-merged egress-proxy cert fix (#133); no code change beyond version bump.
- What it does: Bumps @tangle-network/browser-agent-driver from 0.35.3 to 0.35.4 in package.json. This is the Changesets release PR that triggers automated npm publishing via OIDC once merged. The sole file changed is package.json:5 (version field).
- Goals it achieves: Publish the fix from PR #133 (accept the sandbox egress proxy's MITM certificate browser-wide when EGRESS_PROXY_IP is present) to npm consumers. This is the mandatory release step in the repo's flow: feature PR merges → Changesets opens this version-bump PR → merging it publishes.
- Assessment: This is the exact, intended release mechanism described in CLAUDE.md ('Releases' section) and matches prior release PRs in git history (#132 at a40680b, #130 at a21580b, #128 at 9dcd37e, #121 at 142bb1e — all 'Release: version packages' / 'chore: version packages'). Patch bump is correct: #133 is a bug fix (browser startup stall), warranting patch not minor. The changeset summary in the PR body is
- Better / existing approach: none — this is the repo's canonical release flow; the version bump is generated by the Changesets action and cannot meaningfully be simplified or replaced
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content
🎯 Usefulness — sound
Release of a well-scoped fix that closes a real browser-startup stall behind the managed egress proxy, routed through the codebase's single launch-plan path.
- Integration: Reachable and consumed. The flag is appended to
browserArgsinside theif (managedEgressProxy)block ofbuildBrowserLaunchPlan(src/browser-launch.ts:166-168).browserArgsis a field of the sharedBrowserLaunchPlanand flows to the actual Chromium launch at src/cli/commands/run.ts:442 and :517 (args: launchPlan.browserArgs), and the plan is re-exported for external consumers at src/ind - Fit with existing patterns: Fits the established pattern exactly. The codebase already auto-wires the managed egress proxy and accepts its MITM cert page-wide via
ignoreHTTPSErrors(landed in PR #103, CHANGELOG:125; documented at src/browser-launch.ts:20-27 as acceptable because it is gated on the EGRESS_PROXY_IP sentinel). Per-contextignoreHTTPSErrorsonly covers page traffic, not Chromium's internal service requests — - Real-world viability: Robust on the real path. The guard
if (!browserArgs.includes('--ignore-certificate-errors'))prevents duplicate flags if a profile already sets it (src/browser-launch.ts:166). The block is entered only whenmanagedEgressProxyis truthy, which itself requires the EGRESS_PROXY_IP sentinel AND the absence of an explicit--proxy/BAD_PROXY_URL(src/browser-launch.ts:144-148), so explicit user p - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
No concerns — sound change, no better or existing approach found. ✅
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
✅ No Blockers —
|
tangletools
left a comment
There was a problem hiding this comment.
✅ Clean — 03aa00c0
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
Full immutable report for this review: trace
Summary comment for this run: full summary
tangletools · 2026-07-14T11:39:23Z · immutable trace
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
@tangle-network/browser-agent-driver@0.35.4
Patch Changes
4bc3ed4Thanks @AtelyPham! - Fix a browser startup stall under managed egress isolation. When routed through the sandbox's TLS-intercepting egress proxy, Chromium's own internal service requests (component update, GCM, sign-in probes, variations seed) validate TLS against Chrome's built-in trust store — which does not contain the proxy's MITM CA — and are not covered by the per-contextignoreHTTPSErrorsthat only applies to page traffic. Those requests failERR_CERT_AUTHORITY_INVALID(net_error -202) and Chromium retries them for minutes, wedging the first navigation long past the sandbox'sterminals/commandsbudget and surfacing to callers asorchestrator connect timeout. Accept the proxy's certificate browser-wide (--ignore-certificate-errors) when — and only when — the managed egress proxy is auto-wired (EGRESS_PROXY_IPpresent). Explicit user proxies (--proxy/BAD_PROXY_URL) keep full certificate validation.