firewall: preserve unfinished interactive follow-up work by YMRYMR · Pull Request #352 · YMRYMR/vigil

YMRYMR · 2026-05-24T04:13:55Z

Summary

preserve the remaining phase19-p5-ep2 firewall follow-up work in a reviewable path
surface the current branch delta touching active-response internals, firewall UI, inspector integration, tray behavior, settings, and related UI glue
keep this as a draft until the current compile/API compatibility failures are repaired and CI is green

Why

This branch still contains meaningful unmerged work, but it is not merge-ready. Keeping it as a draft PR preserves the work in a reviewable path without implying the branch is ready to land as-is.

Current branch scope

Based on comparison against current master, this branch changes:

src/autoruns.rs
src/config.rs
src/main.rs
src/platform/tray.rs
src/security/active_response.rs
src/security/active_response_impl.rs
src/security/firewall/mod.rs
src/ui/firewall.rs
src/ui/inspector.rs
src/ui/mod.rs
src/ui/settings/draft.rs
src/ui/uninstall.rs
src/yara_rules.rs
src/yara_scan.rs

Current status

draft intentionally remains enabled
review threads are currently resolved/outdated, but prior review-body concerns should still be rechecked after the compile break is fixed
cargo fmt --check passes on the attached CI run
cargo clippy fails on the current PR merge ref with compile/API compatibility errors, so build/test jobs are skipped
examples from the failing CI log include scheduled-lockdown config field type drift, stale ConnEvent::Closed destructuring, a missing active_response::suspend_process argument, a non-exhaustive handle_inspector_action match, and owned String payload mismatches in src/ui/inspector.rs

Next useful action

Run a focused compatibility pass between the rewritten UI flow and the current Config, ConnEvent, inspector::Action, and active_response APIs, then rerun CI before considering this for review or merge.

YMRYMR · 2026-05-24T05:11:00Z

Checked the current CI signal on this draft. The failing CI run is blocked at cargo fmt --check only, specifically two formatting-only spots in src/ui/mod.rs around the RequestAdmin match arm and the network-action overlay label. I’m leaving this as a draft preservation PR for now, since it is still substantially behind master, but the immediate blocker is narrow and mechanical rather than a deeper runtime failure.

YMRYMR · 2026-05-24T06:15:10Z

Scheduled follow-up check complete. There are still no review submissions, requested changes, or unresolved review threads on this draft. CI remains the only concrete blocker: the CI workflow is still failing at cargo fmt --check, and the job log still points to the two formatting-only spots in src/ui/mod.rs around the RequestAdmin match arm and the network-action overlay label. I did not leave a code change on the branch from this run because this environment could not safely materialize a local checkout for a clean rustfmt pass, and a direct file rewrite risked broader churn on a draft branch that is already substantially behind master. Validation used here: PR metadata, review-thread inspection, requested-review state, and the failing Actions job log for run 26279766972.

YMRYMR · 2026-05-24T08:14:59Z

Applied the formatting-only fix that cargo fmt --check was asking for in src/ui/mod.rs on branch phase19-p5-ep2.

This was limited to the two rustfmt rewrites called out by the failing CI log:

the inspector::Action::RequestAdmin match arm
the network-action overlay helper text construction

I’m leaving the PR as a draft because it is still a preservation branch that is substantially behind master, but the concrete CI blocker identified in the previous checks has now been addressed on the branch. GitHub had not attached a fresh workflow run to the new head at the time of this note, so the next useful signal is the rerun status on commit f1ae7ae0ac6bb1dff5a8ef4e5bb3bfee3da74192.

YMRYMR · 2026-05-24T09:10:40Z

Checked this draft again from the current head. There are still no review submissions or unresolved review threads, but I found a concrete code-level blocker that keeps it in draft territory.

src/ui/mod.rs still matches on inspector::Action::IsolateMachine, inspector::Action::RestoreNetwork, and inspector::Action::Copy(...), while src/ui/inspector.rs no longer declares those enum variants on the branch head. That leaves the current delta in an internally inconsistent state and not ready to move toward merge.

I’m leaving the PR open as the preservation path for the remaining firewall work, but the next useful step is to reconcile the inspector action enum with the handler paths before spending time on broader review or merge readiness.

YMRYMR · 2026-05-24T10:10:52Z

Checked the draft against the current branch head and confirmed a concrete integration blocker in the firewall UI follow-up.

This branch intentionally removes Action::IsolateMachine and Action::RestoreNetwork from src/ui/inspector.rs and drops the per-process isolation button there, but src/ui/mod.rs still matches on those inspector action variants in handle_inspector_action. That leaves the branch head internally inconsistent even before broader review against current master.

I’m leaving the PR open as the preservation path for the remaining firewall work, but the next useful step is to reconcile the inspector action enum and the stale handler arms in src/ui/mod.rs so the draft reflects one coherent interaction model.

YMRYMR · 2026-05-24T11:11:12Z

Follow-up check on the current draft head: the inspector mismatch is narrower and more mechanical than the earlier note suggested, but it is still a real compile/integration blocker.

src/ui/inspector.rs no longer exposes Action::IsolateMachine, Action::RestoreNetwork, or Action::Copy(...) on this branch. src/ui/mod.rs still carries stale handling for those removed variants in three places:

handle_inspector_action
the PendingResponse enum plus the confirm-dialog title/body mapping
the confirmation execution match that still branches on PendingResponse::IsolateMachine and PendingResponse::RestoreNetwork

That leaves the branch head internally inconsistent even before broader review against current master. The next useful change is a focused cleanup in src/ui/mod.rs to remove those dead inspector-action paths and keep the network restore flow only through the newer firewall-tab action plumbing.

YMRYMR · 2026-05-24T13:14:09Z

Applied a narrow follow-up fix on phase19-p5-ep2 to restore the inspector action variants that src/ui/mod.rs still handles on this branch head.

Changed:

re-added Action::IsolateMachine
re-added Action::RestoreNetwork
re-added Action::Copy(String)

Why this shape: on the current draft head, src/ui/mod.rs still matches those inspector actions and confirm paths, but src/ui/inspector.rs no longer declared the variants. Restoring the enum entries is the smallest in-scope fix that makes the branch internally consistent again without broadening the draft’s behavior.

Validation used here:

checked the PR for new review threads, reviews, requested changes, and CI signals
verified the branch head advanced to 0ffdba5a1ae4a1595db3ed2fb5c8087a35a38ffb
re-read src/ui/inspector.rs on the updated head and confirmed the enum now includes the variants that src/ui/mod.rs expects

There is still no fresh GitHub Actions run or commit status attached to this new head from this environment, so compile/test confirmation is still pending the next CI run.

YMRYMR

A couple of blocking issues stood out on review, so I’d keep this in draft for now.

The new firewall row-to-inspector interaction looks non-functional as written. In src/ui/firewall.rs, the selection path hangs off resp.response.clicked() from ui.horizontal(...) and resp.clicked() from ui.label(...), but those widgets/layout responses are hover-only by default in egui. That means the advertised “click any rule for details and actions” flow likely never fires for isolation, blocked IPs, blocked processes, blocked domains, or suspended processes. I’d switch each row to an explicitly clickable widget (selectable_label, Button, or a custom Sense::click() interaction on the row rect) before this moves forward.
refresh_inspector_snapshot in src/ui/mod.rs now throttles snapshot fetches even when the selection key changes. After key_changed is detected, the new code only starts a worker when self.inspector_snapshot_rx.is_none() && self.inspector_snapshot_last_started.elapsed() >= INSPECTOR_SNAPSHOT_REFRESH. That means if the user changes selections inside the refresh window, the inspector can sit blank/stale until the timer expires. Current master bypasses the refresh throttle on key changes; this branch should preserve that behavior.

There are still no review threads or CI signals on the PR, so I’m leaving it as a draft preservation branch rather than trying to merge it yet.

YMRYMR · 2026-05-24T15:10:33Z

Applied a narrow follow-up fix on phase19-p5-ep2 for the first blocking review point in src/ui/firewall.rs.

Changed:

replaced the non-clickable ui.horizontal(...).response.clicked() and ui.label(...).clicked() selection hooks with explicit ui.interact(..., Sense::click()) row interactions for isolation, blocked IPs, blocked processes, blocked domains, and suspended processes
kept the existing rendering and right-panel action flow intact, while making the advertised row-to-inspector selection path actually clickable

Validation used here:

verified the PR head advanced to 31fc02aa0c4456aeea12ba480dea94bde9f4901d
re-read the updated branch copy of src/ui/firewall.rs and confirmed each selectable row now creates an explicit click-sense response with a stable widget id
checked for fresh CI/status signals on the new head; GitHub has not attached any workflow run or commit status yet from this environment

I did not apply the refresh_inspector_snapshot follow-up from the same review in this run. That second issue is still actionable, but it lives in the much larger src/ui/mod.rs surface, and I did not want to hand-rewrite that file from this scheduled environment without a cleaner validation path.

YMRYMR · 2026-05-24T16:10:20Z

Checked the current draft head again.

There are still no workflow runs or commit-status checks attached to 31fc02aa0c4456aeea12ba480dea94bde9f4901d, and the remaining blocker from the earlier review is still the inspector refresh path in src/ui/mod.rs.

The issue is the same one called out in review point 2: after key_changed, refresh_inspector_snapshot still waits for self.inspector_snapshot_last_started.elapsed() >= INSPECTOR_SNAPSHOT_REFRESH before starting a new worker. That means rapid selection changes can leave the inspector blank or stale until the throttle window expires.

The next useful fix is still to let a changed selection bypass that throttle, matching current master behavior. I’m leaving this as draft-only for now rather than merging without that follow-up or any fresh validation signal.

YMRYMR · 2026-05-24T20:15:17Z

Applied the remaining concrete review follow-up on phase19-p5-ep2 in src/ui/mod.rs.

Changed:

refresh_inspector_snapshot now starts a new snapshot worker immediately when the inspector selection key changes
the existing 1-second throttle still applies to repeated refreshes for the same selection when nothing changed

Why this shape: the prior branch logic cleared the inspector on key_changed but still waited for INSPECTOR_SNAPSHOT_REFRESH before launching a new worker, which could leave the panel blank or stale after rapid selection changes. This keeps the branch behavior aligned with the review expectation without broadening the rest of the draft.

Validation used here:

verified the PR head advanced to e3681710f49a55d89a71c910dd1ff9f3a0c32967
re-read the updated refresh_inspector_snapshot logic on the branch head and confirmed key_changed now bypasses the throttle gate
checked for fresh GitHub Actions and commit-status signals on the new head; there are still none attached from this environment

I did not move the PR out of draft. It remains a preservation branch that is substantially behind current master, and compile/test confirmation is still pending a fresh CI run or a fuller local validation pass.

YMRYMR · 2026-05-24T21:12:06Z

Checked the current draft head (e3681710f49a55d89a71c910dd1ff9f3a0c32967) again.

The earlier refresh_inspector_snapshot concern from review point 2 does not reproduce on the current branch state anymore. In src/ui/mod.rs, the current logic now starts a new snapshot worker immediately when key_changed is true and only applies the INSPECTOR_SNAPSHOT_REFRESH throttle when the selection key is unchanged.

That means rapid selection changes should no longer sit behind the refresh window in the way the earlier review comment described.

I’m still keeping this as a draft preservation PR and not moving it toward merge from this run because:

the branch is still substantially diverged from master (ahead 60, behind 21)
GitHub is not currently attaching any workflow runs or commit-status checks to this head from this environment
mergeable is still reporting false

So the queue status here is: the old snapshot-throttle blocker appears addressed on the current head, but the PR is still not in a merge-ready state.

YMRYMR · 2026-05-24T23:08:31Z

Scheduled follow-up on the current draft head (e3681710f49a55d89a71c910dd1ff9f3a0c32967).

The earlier blocking review points around clickable firewall rows and refresh_inspector_snapshot no longer appear outstanding on the current branch state:

src/ui/firewall.rs now uses explicit click-sense row interactions for the selectable firewall entries
src/ui/mod.rs now lets key_changed bypass the inspector refresh throttle

There are still no unresolved review threads or requested changes on the PR.

I’m still leaving this in draft and not moving it toward merge from this run because the concrete remaining blockers are repository-state blockers rather than the earlier code-review ones:

the branch is still substantially diverged from master (ahead 60, behind 21)
GitHub is not attaching any workflow runs or commit-status checks to the current head from this environment
PR metadata is still reporting mergeable: false

So the next useful step is not another small UI follow-up. It is to rebase or otherwise reconcile this preservation branch against current master, then get a fresh validation signal on the updated head before treating it as mergeable work.

YMRYMR · 2026-05-25T01:08:31Z

Checked the current draft head again with the branch-vs-master comparison.

The earlier code-review blockers around clickable firewall rows and the inspector snapshot throttle appear addressed on the current head, and there are still no unresolved review threads or requested changes.

The remaining blocker is now branch reconciliation rather than another small follow-up inside the draft. Since merge-base 884e59161cf09957c035c5fed93a0d7d2406ffa3, current master has also moved on the same files this draft still changes:

src/security/firewall/mod.rs
src/ui/firewall.rs
src/ui/inspector.rs
src/ui/mod.rs
src/ui/tab_bar.rs
tests/firewall_cli_smoke_test.sh
tests/firewall_integration_test.sh
tests/vm_test_runner.ps1

So the current state is:

PR compare still shows ahead 60, behind 21
PR metadata is still reporting mergeable: false
there are still no attached workflow runs or commit-status checks on the current head from the available signals here

I’m keeping this in draft. The next useful step is to rebase or otherwise reconcile phase19-p5-ep2 against current master, then get a fresh validation signal on the updated head before treating the remaining firewall delta as merge-ready.

YMRYMR · 2026-05-25T11:07:42Z

Scheduled follow-up on the current draft head (e3681710f49a55d89a71c910dd1ff9f3a0c32967).

The earlier code-review blockers around clickable firewall rows and the inspector snapshot throttle still appear addressed on the current branch state, and there are still no unresolved review threads or requested changes.

The remaining blocker is still branch reconciliation rather than another small follow-up inside the draft:

compare against current master is still ahead 60, behind 21
PR metadata is still reporting mergeable: false
there are still no attached workflow runs or commit-status checks on the current head from the available signals here

I’m keeping this in draft. The next useful step is still to rebase or otherwise reconcile phase19-p5-ep2 against current master, then get a fresh validation signal on the updated head before treating the remaining firewall delta as merge-ready.

chatgpt-codex-connector · 2026-05-25T11:43:00Z

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

YMRYMR · 2026-05-25T12:09:05Z

Aligned the PR state with its current readiness and moved it back to draft.

Current branch readback still shows the earlier code-review blockers addressed:

src/ui/firewall.rs now uses explicit click-sense row interactions for firewall selections
src/ui/mod.rs now lets key_changed bypass the inspector snapshot throttle

I’m not merging from this run because the remaining blockers are branch-state blockers rather than another small code follow-up:

compare vs master is still ahead 60, behind 21
PR metadata is still reporting mergeable: false
there are still no attached workflow runs or commit-status checks on head e3681710f49a55d89a71c910dd1ff9f3a0c32967 from the available signals here

Next useful step: rebase or otherwise reconcile phase19-p5-ep2 against current master, then get a fresh validation signal on the updated head before treating the remaining firewall delta as merge-ready.

YMRYMR · 2026-05-25T13:06:14Z

Scheduled follow-up on the current draft head (e3681710f49a55d89a71c910dd1ff9f3a0c32967).

I checked for new review submissions, unresolved review threads, requested changes, commit statuses, and GitHub Actions runs. There are still no unresolved threads or requested changes, and GitHub is still showing no attached commit-status checks or workflow runs for this head from the available signals here.

I did not make a code change in this run because there is no new narrow in-scope fix to apply safely. The remaining blocker is still branch-state reconciliation rather than another isolated follow-up inside the draft:

compare vs master is still ahead 60, behind 21
PR metadata is still reporting mergeable: false

Validation used here:

PR metadata and compare state
review submission and review-thread inspection
commit-status readback for e3681710f49a55d89a71c910dd1ff9f3a0c32967
workflow-run lookup for the same head

Next useful step remains to rebase or otherwise reconcile phase19-p5-ep2 against current master, then get a fresh validation signal on the updated head before treating the remaining firewall delta as merge-ready.

YMRYMR · 2026-05-25T13:10:55Z

Checked the current draft head e3681710f49a55d89a71c910dd1ff9f3a0c32967.

The earlier refresh_inspector_snapshot blocker from review point 2 no longer reproduces on the live branch state: when the selection key changes, src/ui/mod.rs now starts a new inspector worker immediately instead of waiting for the refresh throttle window. So that specific review note is stale on the current head.

I’m still leaving this as a draft. There are no unresolved review threads or requested changes at the moment, but GitHub still shows no workflow runs or commit-status checks attached to the current head from this environment, and the PR body still describes this as a preservation branch that is substantially behind master. The next useful step is fresh validation on the current head before deciding whether to keep iterating toward merge or continue treating this as parked branch preservation work.

YMRYMR · 2026-05-25T16:06:34Z

Scheduled follow-up on the current draft head (e3681710f49a55d89a71c910dd1ff9f3a0c32967).

I checked for new PR comments, review submissions, unresolved review threads, requested changes, commit-status checks, and GitHub Actions runs. There are still no unresolved threads or requested changes, and GitHub is still showing no attached commit-status checks or workflow runs for this head from the available signals here.

I did not make a code change in this run because there is no new narrow in-scope fix to apply safely. The remaining blocker is still broader branch-state reconciliation rather than another isolated follow-up inside the draft:

compare vs master is still ahead 60, behind 21
PR metadata is still reporting mergeable: false

Validation used here:

PR metadata and compare state
PR discussion and review submission readback
review-thread inspection
commit-status readback for e3681710f49a55d89a71c910dd1ff9f3a0c32967
workflow-run lookup for the same head

I’m keeping this in draft. A rebase or other reconciliation against current master is still a broader step, so I’m not doing that unilaterally from this scheduled pass.

YMRYMR · 2026-05-25T18:11:13Z

Checked the current draft head again.

The earlier inspector refresh blocker from review point 2 is addressed on the branch now. Commit e3681710f49a55d89a71c910dd1ff9f3a0c32967 changes refresh_inspector_snapshot so a changed selection key starts a new snapshot worker immediately instead of waiting for the regular refresh window.

I’m keeping the PR in draft because it is still a preservation branch with no attached CI or commit-status signal on the current head from this environment, and the branch remains substantially behind master. The immediate review concern is no longer the selection-throttle path; the next useful step is a fresh validation pass once checks are available or the draft is rebased into a more reviewable state.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e3681710f4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-05-25T20:53:59Z

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

YMRYMR · 2026-05-25T21:13:04Z

Checked the current head 8beed9d17eb7660f809e5292e9f8261d5a7f194e against the new review feedback and I’m keeping this in draft.

The two open blockers both still reproduce on the live branch state:

refresh_active_response_state now polls active_response::status() but no longer runs active_response::reconcile(), so expired isolation / firewall state can stick around until some other path happens to reconcile it
scheduled isolate/restore still flips scheduled_lockdown_active when the background operation is enqueued instead of when the result comes back, so a failed network action can leave the scheduler’s state out of sync with the real isolation state

There are also still no attached commit-status checks or workflow runs on this head from the available signals here, and the branch remains diverged from master (ahead 61, behind 21). I’m not merging or forcing further state changes from this pass.

YMRYMR · 2026-05-25T21:13:34Z

Scheduled follow-up on the current draft head 8beed9d17eb7660f809e5292e9f8261d5a7f194e.

There are two new unresolved review threads, both in src/ui/mod.rs, and both look like real state-management blockers rather than style or polish:

the periodic UI refresh path now polls active_response::status() without calling active_response::reconcile(), which can leave expired containment state stuck until some other path reconciles it
scheduled_lockdown_active is still flipped when isolate/restore is queued, before the background result confirms success, which can desynchronize the scheduler from actual network-isolation state on failure

I did not apply another code change from this scheduled pass. The draft is still substantially behind master, mergeable is still false, and this environment still does not provide a clean local checkout or Rust validation path for a safe edit in this larger stateful file. Starting unrelated roadmap work would also be churn while these blockers are open.

Validation used here:

PR metadata for head state and mergeability
review-thread inspection
review submission readback
commit-status readback for the current head (still no attached statuses from the available signals here)

YMRYMR · 2026-05-31T08:14:04Z

Scheduled maintenance check on the current head 3552edd:

Review threads remain resolved/outdated; I did not find a new review-thread blocker.
cargo fmt --check now passes.
The CI workflow is still failing in Format & lint, now at cargo clippy, with compile/API compatibility errors rather than formatting drift.
The branch is 26 commits ahead of master and 3 commits behind it, so this still looks like a draft preservation/reconciliation PR rather than a merge candidate.

The concrete next step is a focused compatibility pass across the rewritten UI flow and current APIs. The failing log points at the known drift areas: scheduled-lockdown schedule shape, ConnEvent::Closed destructuring, active-response wrapper calls such as suspend/quarantine/autorun helpers, and the expanded inspector::Action variants that handle_inspector_action does not fully cover yet.

I’m leaving this draft unmerged.

YMRYMR · 2026-05-31T18:09:51Z

Scheduled maintainer pass complete.

Current state from head 3552edda2c4c3c665227c5e6113217a614f18f2f:

no unresolved review threads remain; the prior firewall row clickability and inspector refresh concerns appear addressed in the current branch code
most workflows are green, but CI is still failing in Format & lint
cargo fmt --check now passes; the failing step is cargo clippy, which currently stops on compile/API compatibility errors

The concrete compile blockers I verified from the failing job/code include:

refresh_active_response_state in src/ui/mod.rs is still mixing config::LockdownSchedule with active_response::LockdownSchedule, and also treats scheduled_lockdown_* u8 fields as Option values via .map() / .unwrap_or(...)
the ConnEvent::Closed match arm in src/ui/mod.rs still destructures the old proc_name, local_addr, and remote_addr fields, while the current event carries pid, local, remote, and snapshot

I’m leaving the PR as draft and unmerged. The next useful action is a focused compile-compatibility pass in src/ui/mod.rs, especially around scheduled-lockdown schedule construction and the closed-connection event handling path, followed by a fresh CI run.

YMRYMR · 2026-05-31T21:11:17Z

Maintainer pass: #352 is still correctly blocked as a draft. The latest head (3552edd) has green auxiliary checks, but the main CI run still fails in cargo clippy during compilation. The failures are compatibility issues in the unfinished UI/API rewrite, including the scheduled-lockdown schedule type drift, stale ConnEvent::Closed destructuring, and the non-exhaustive inspector action match.

I could inspect the PR and CI state through the GitHub connector, but this execution environment cannot clone the repo (CONNECT tunnel failed, response 403), and the connector update path would require replacing the full large src/ui/mod.rs file. I did not risk a partial or unverified edit. Next useful action remains a focused local compatibility pass on src/ui/mod.rs against the current Config, ConnEvent, inspector::Action, and active-response APIs, then rerun CI before review/merge.

YMRYMR · 2026-06-01T00:15:10Z

Maintenance pass update:

Added serde derives to active_response::LockdownSchedule so the schedule type can be persisted through config once the branch is unified on that shape.
Re-ran CI on head ca555412; non-CI checks that completed are green, but CI / Format & lint still fails in cargo clippy with 40 compile errors.
The remaining blockers are still the larger compatibility pass called out in the PR body, especially the Config.lockdown_schedule type drift, stale ConnEvent::Closed destructuring in src/ui/mod.rs, the two-arg/three-arg active-response process action call sites, and the non-exhaustive inspector::Action match.

Keeping this draft open; it is not merge-ready yet.

YMRYMR · 2026-06-01T08:12:10Z

Scheduled maintenance pass complete on the current head (ca555412).

Current state:

PR remains correctly marked as draft.
Review threads are resolved/outdated; I did not find an unresolved review thread that needs a reply today.
The branch is still diverged from master (27 ahead, 3 behind).
Latest head checks are mixed: security/dependency workflows are green, but CI is still failing in Format & lint at cargo clippy with compile/API compatibility errors, so build/test remains skipped.

The next useful action is still a focused compatibility pass against current master APIs before review readiness. The visible blockers include the scheduled-lockdown config shape in src/ui/mod.rs, stale ConnEvent::Closed handling, and non-exhaustive inspector action handling. I did not merge or mark this ready because the compile failure is substantive.

YMRYMR · 2026-06-01T10:11:15Z

Maintenance pass update:

Rechecked the earlier review-body concerns: the firewall rows now use explicit Sense::click() interactions, and inspector snapshots refresh immediately when the selection key changes.
Latest PR-head checks still leave this draft blocked: CI / Format & lint fails in cargo clippy with compile/API compatibility errors, while the other reported workflows are green.
I did not merge or mark this ready. The next useful step is still a focused compile-compatibility pass on the current branch, then rerun CI before requesting review.

YMRYMR · 2026-06-01T11:12:43Z

Scheduled maintainer check on current head ca5554126634a9340da728eef6bc82ea15ab7335:

Open PR queue is down to this single draft PR.
Review submissions are comment-only, and all current review threads are resolved or outdated.
Latest attached checks are mostly green, but CI run 26728546894 still fails in Format & lint at cargo clippy; cargo fmt --check now passes.
The clippy failure is still a compile/API compatibility pass rather than a style-only issue. The log reports 40 compile errors, including stale scheduled-lockdown schedule construction, ConnEvent::Closed destructuring drift, and a non-exhaustive handle_inspector_action match for newer inspector actions.

I’m leaving this as a draft and not merging. The next useful change is a focused compile repair in src/ui/mod.rs against the current Config, ConnEvent, and inspector::Action shapes, then rerun CI.

YMRYMR · 2026-06-01T12:11:54Z

Scheduled follow-up check complete. Current head ca5554126634a9340da728eef6bc82ea15ab7335 has no open requested-change reviews and all review threads are resolved or outdated. The only live blocker is the CI workflow run 26728546894: dependency/security workflows are green, but Format & lint fails during cargo clippy after cargo fmt --check passes.

I did not push a fix from this scheduled run because the failure is no longer a narrow formatter issue; the clippy/build log reports a broad compile/API compatibility cluster, and the code confirms multiple in-scope but cross-cutting errors in src/ui/mod.rs, including scheduled-lockdown config type drift, stale ConnEvent::Closed field handling, and a non-exhaustive inspector::Action match. Those should be fixed with a focused compatibility pass and then validated with local cargo fmt --check and cargo clippy, rather than by a speculative remote edit.

YMRYMR · 2026-06-01T15:12:53Z

Maintenance pass update: this should remain draft for now.

Latest CI on ca5554126634a9340da728eef6bc82ea15ab7335 still has Format & lint failing at cargo clippy; the other visible checks are green. The remaining blocker is compile/API compatibility rather than review-thread cleanup. The current failures still line up with the known compatibility pass areas: scheduled-lockdown schedule type conversion, ConnEvent::Closed destructuring, inspector action exhaustiveness, and owned String values from inspector targets.

I did not merge or mark this ready because the build is not green and the PR is intentionally preserving unfinished work.

YMRYMR · 2026-06-01T19:11:58Z

Maintainer pass update: leaving this as a draft and not merge-ready.

The latest head still has a failing CI Format & lint run (cargo clippy) with compile/API compatibility blockers. The actionable fixes I verified are concentrated in src/ui/mod.rs:

convert cfg.lockdown_schedule into the active_response::LockdownSchedule shape before calling active_response::schedule_contains, and use the legacy scheduled-lockdown u8 fields directly instead of treating them as Options
update ConnEvent::Closed handling to match the current event shape (pid, local, remote, snapshot) instead of destructuring removed proc_name / local_addr / remote_addr fields
add arms for the remaining inspector::Action variants (Trust, OpenLocation, KillConfirmed, KillCancelled) so the action match is exhaustive
recheck the response wrapper calls after that pass, especially suspend/autorun/quarantine naming, against the current active_response facade

All review threads I saw are resolved or outdated, so the next useful step is a compile-fix pass followed by rerunning CI before this is marked ready for review.

YMRYMR · 2026-06-01T19:19:34Z

Scheduled follow-up update:

Replaced the glob re-export in src/security/active_response.rs with an explicit facade export list so the compatibility wrappers in that module are no longer shadowed by implementation functions with different signatures.
Followed up with a rustfmt-order fix after the first rerun failed at cargo fmt --check.

Validation on the latest commit 4660140:

cargo fmt --check now passes in CI.
Secret scan, artifact hygiene, dependency review, OSSF Scorecard, and Snyk Open Source are green.
cargo clippy still fails, so the draft remains blocked. The remaining failures are still broader API compatibility issues in this branch, including the unresolved handle_inspector_action exhaustiveness error and related compile/API drift called out in the PR body.

YMRYMR · 2026-06-01T20:12:53Z

Scheduled maintenance check complete.

Current head 46601405d8ea03099d0d2d32bf20239d4dff25dc has fresh workflow signal: the earlier formatting blocker is fixed (cargo fmt --check passes), and the remaining failing workflow is CI at cargo clippy. The other visible workflows on this head are green.

I inspected the remaining failure path and this should stay draft. The next useful compatibility pass is focused in src/ui/mod.rs:

convert cfg.lockdown_schedule from config::LockdownSchedule into the active-response schedule shape before calling active_response::schedule_contains
stop treating scheduled_lockdown_* fields as Option; they are plain u8 fields on current Config
update the ConnEvent::Closed match arm to the current { pid, local, remote, snapshot } shape
make handle_inspector_action exhaustive for Trust, OpenLocation, KillConfirmed, and KillCancelled, preserving the existing trust/open-location behavior and the inline kill confirmation flow

I did not merge or mark this ready for review. There are no unresolved review threads, but CI still has compile errors and the PR is correctly still a preservation draft.

YMRYMR · 2026-06-02T01:12:15Z

Scheduled maintenance check complete.

Current status on head 46601405d8ea03099d0d2d32bf20239d4dff25dc:

no unresolved review threads are visible
the PR is still correctly marked as draft
cargo fmt --check is passing in the latest CI run
the remaining blocker is cargo clippy, which fails at compile time with 42 errors; the build/test matrix is skipped behind that failure

The next useful compatibility pass remains focused in src/ui/mod.rs: convert Config::lockdown_schedule into the active-response schedule shape before calling schedule_contains, stop treating the legacy scheduled-lockdown hour/minute fields as Option, update the ConnEvent::Closed handler to the current { pid, local, remote, snapshot } event shape, and make handle_inspector_action exhaustive for Trust, OpenLocation, KillConfirmed, and KillCancelled.

I did not push a direct code rewrite from this scheduled run because this environment cannot clone the branch or run local Rust verification, and applying a full-file GitHub contents replacement to src/ui/mod.rs without a compile pass would be too risky for this draft preservation branch.

YMRYMR · 2026-06-02T07:09:49Z

Scheduled maintenance check complete.

Current status on head 46601405d8ea03099d0d2d32bf20239d4dff25dc:

the PR is still correctly marked as draft
no unresolved review threads are visible; prior review comments are resolved or outdated
the latest visible workflow set still has only CI failing; secret scan, artifact hygiene, dependency review, OSSF Scorecard, Snyk, CodeQL, and ClusterFuzzLite are green
inside CI, cargo fmt --check passes and cargo clippy fails at compile time, so the build/test matrix remains skipped

I rechecked the failure shape against the branch and current master. The blocker is broader than a safe one-line patch: the draft branch still carries an older active-response module split while the base branch has moved API definitions directly in src/security/active_response.rs, and src/ui/mod.rs also needs merge-ref compatibility updates for scheduled lockdown handling, ConnEvent::Closed, and the inspector actions Trust, OpenLocation, KillConfirmed, and KillCancelled.

I did not push a direct code update from this scheduled run because the environment still cannot clone the repository for a local compile/rustfmt pass, and replacing large files through the GitHub contents API without verification would be too risky for this preservation draft. Next useful action remains a local rebase/compatibility pass with cargo clippy on the PR merge result before marking this ready for review.

YMRYMR · 2026-06-02T12:11:29Z

Scheduled maintenance check on the latest head 46601405d8ea03099d0d2d32bf20239d4dff25dc:

Review state: no unresolved review threads remain; earlier Codex threads are resolved/outdated.
CI state: most auxiliary workflows are green, but the main CI workflow still fails.
Current blocker: cargo fmt --check now passes, but cargo clippy fails during compilation with 42 Rust errors, including API drift around ui::inspector::Action handling and related active-response/UI compatibility issues.

I’m leaving this as a draft preservation PR. The next useful action is a focused compatibility pass against current master APIs, then rerun CI before requesting review or considering merge.

YMRYMR · 2026-06-02T14:11:17Z

Maintainer pass update: keeping this PR in draft and unmerged.

The latest CI failure is still the right blocker. Review threads are resolved/outdated, but the branch still has compile/API drift to repair before it should be reviewed for merge. Confirmed remaining areas from the current branch/code state:

src/ui/mod.rs still matches ConnEvent::Closed with old fields (proc_name, local_addr, remote_addr), while the current event shape is { pid, local, remote, snapshot }.
refresh_active_response_state mixes config::LockdownSchedule with active_response::LockdownSchedule; the minute-based config schedule needs conversion before calling active_response::schedule_contains.
handle_inspector_action is non-exhaustive for the newer inspector actions (Trust, OpenLocation, KillConfirmed, KillCancelled). Those should be wired to the existing trust/open-location/kill-confirm flows rather than ignored.

I could not safely push the compatibility patch from this scheduled run because the runtime cannot clone/download GitHub raw content, and the connector edit path requires whole-file replacement. No merge attempted.

YMRYMR · 2026-06-02T16:13:13Z

Scheduled maintenance check on the current head (46601405d8ea03099d0d2d32bf20239d4dff25dc) found that the queue is down to this single draft PR, with no unresolved review threads. The blocker is still CI: run 26776427228 has cargo fmt --check passing, but cargo clippy fails before build/test with 42 compile errors.

Two concrete current-head issues are visible from the source and failing log:

src/ui/mod.rs still treats scheduled lockdown as the old active-response schedule shape. Current Config::lockdown_schedule is Option<config::LockdownSchedule> with days, start_minute, and end_minute, while refresh_active_response_state tries to fall back through cfg.scheduled_lockdown_start_hour.map(...) and construct active_response::LockdownSchedule { start_hour, start_minute, end_hour, end_minute }. That needs to be converted to config-schedule matching, including day/minute checks, instead of mixing the two schedule types.
handle_inspector_action is non-exhaustive for the current inspector::Action enum. The clippy log tail specifically reports missing coverage for KillConfirmed and KillCancelled; the same match also needs explicit handling for Trust and OpenLocation. KillConfirmed can reuse the existing modal kill behavior in this file, and KillCancelled should clear kill_confirm.

I did not push a branch update from this run because this environment cannot materialize a clean checkout or raw file download for a safe full-file update, and the connector returns this large UI file truncated in the chat view. I’m leaving the PR as a draft and not merging; the next useful pass is a small compatibility patch in src/ui/mod.rs, then rerun cargo clippy on the PR head.

YMRYMR · 2026-06-02T18:09:41Z

Scheduled maintenance check complete on current head 46601405d8ea03099d0d2d32bf20239d4dff25dc.

Current state:

PR remains draft and should not be merged.
No unresolved review threads are visible; prior review threads are resolved/outdated.
Latest workflow set still has auxiliary checks green and main CI failing in cargo clippy; cargo fmt --check passes.

The compile blocker is broader than the last source-only note captured. The current failing areas are:

src/ui/inspector.rs: several action constructors pass borrowed values where the enum now requires owned Strings, e.g. Action::UnblockRemote(target.clone()), BlockRemote { target: target.clone() }, Action::UnblockDomain(domain.clone()), and BlockDomain { domain: domain.clone() } need owned-string conversion from the referenced values.
src/ui/mod.rs: scheduled lockdown still mixes config::LockdownSchedule (days, start_minute, end_minute) with active_response::LockdownSchedule (start_hour, start_minute, end_hour, end_minute) and also treats plain u8 legacy fields as Option.
src/ui/mod.rs: ConnEvent::Closed still matches old field names instead of the current { pid, local, remote, snapshot } shape.
src/ui/mod.rs: handle_inspector_action is still non-exhaustive for Trust, OpenLocation, KillConfirmed, and KillCancelled.

I did not push a branch update from this run because this environment still cannot clone or fetch raw GitHub content, and the available connector edit path would require unverified whole-file replacement for large UI files. Next useful action remains a local compatibility patch against the PR merge ref followed by cargo clippy.

YMRYMR · 2026-06-02T21:09:33Z

Maintainer pass update: I rechecked the open PR queue and this is still the only open PR. It should remain draft.

Current blocker is still the cargo clippy compile failure in the CI Format & lint job. The failures are compatibility drift between this branch and current APIs, including:

src/ui/mod.rs treating scheduled-lockdown hour/minute fields as Option<u8> even though Config stores them as plain u8
src/ui/mod.rs passing config::LockdownSchedule to active_response::schedule_contains, which currently expects the separate active_response::LockdownSchedule
stale ConnEvent::Closed destructuring in src/ui/mod.rs; the variant now carries pid, local, remote, and snapshot
non-exhaustive inspector action handling for Trust, OpenLocation, KillConfirmed, and KillCancelled
owned String mismatches in src/ui/inspector.rs for remote/domain action payloads

I did not merge or mark ready. The next useful fix is a focused compatibility pass that unifies the schedule type usage, updates the closed-connection handler to the current event shape, and wires the remaining inspector actions before rerunning CI.

YMRYMR · 2026-06-02T22:11:12Z

CI is still blocked on compile/API compatibility rather than a flaky check. The failing workflow is CI run 26776427228, job Format & lint, step cargo clippy.

The current errors I verified from the log are concentrated in src/ui/mod.rs and src/ui/inspector.rs:

refresh_active_response_state builds/uses schedule values with stale types: the saved config schedule is config::LockdownSchedule, but active_response::schedule_contains expects active_response::LockdownSchedule, and the legacy scheduled_lockdown_* fields are plain u8s rather than Option<u8>s.
handle_event still destructures ConnEvent::Closed using removed fields (proc_name, local_addr, remote_addr) instead of the current { pid, local, remote, snapshot } shape.
handle_inspector_action is non-exhaustive for Trust, OpenLocation, KillConfirmed, and KillCancelled.
Several inspector action cells pass &String values where the action payload now owns String; these need to_string()/owned conversion.

I could not safely push a fix from this scheduled run because this environment cannot clone or download the repository source from GitHub, so I could not run local verification after editing. The next merge-moving step is a focused compatibility pass on those two files, then rerun cargo clippy on the PR merge ref.

YMRYMR · 2026-06-02T23:09:27Z

Maintainer pass update: leaving this as draft and not merge-ready.

The current blocker is still the CI / Format & lint failure at cargo clippy. The failing job reaches cargo fmt --check successfully, then stops on compile/API compatibility errors in the PR merge ref. The main actionable groups I saw are:

scheduled-lockdown wiring is split between config::LockdownSchedule and active_response::LockdownSchedule, and refresh_active_response_state still treats the legacy scheduled_lockdown_* fields like Option<u8> values even though they are plain u8s
ConnEvent::Closed is matched with stale field names (proc_name, local_addr, remote_addr) instead of the current pid, local, remote, snapshot shape
several inspector action builders pass &String values where the action enum now owns String payloads
handle_inspector_action needs to handle the trust/open-location/kill-confirm/kill-cancel action variants added back to inspector::Action

I did not merge or mark this ready. The next useful change is a narrow compatibility patch in src/security/active_response.rs, src/ui/mod.rs, and src/ui/inspector.rs, followed by a rerun of cargo clippy.

YMRYMR · 2026-06-03T02:09:45Z

Maintenance pass update:

Rechecked the open queue: this is the only open PR, and it is still correctly marked as draft.
Verified all current inline review threads are resolved/outdated.
Verified the latest head still has a failing CI workflow; the failing job is Format & lint, specifically cargo clippy, while the other workflows on the head SHA are green.
The current clippy failure is still the known compatibility pass called out in the PR body: scheduled-lockdown config field shape/type drift, config-vs-active-response LockdownSchedule mismatch, stale ConnEvent::Closed destructuring, inspector action ownership mismatches for String payloads, and a non-exhaustive handle_inspector_action match.

I did not merge this PR. The next useful step is still a focused compile/API compatibility patch, followed by rerunning CI and then rechecking the earlier review-body concerns before marking it ready for review.

…lockdown logic (#362) * Respect scheduled lockdown days * Handle overnight scheduled lockdown days * Clear Linux tray alert target on reset

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c629a49573

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-06-03T09:32:59Z

+#[path = "active_response_platform.rs"]
+mod platform;


Keep the platform module at the same parent depth

On Linux, moving the implementation behind active_response::imp changes this #[path] module's parent chain: active_response_platform.rs still imports super::super::linux_command_plan/linux_firewall_backend/linux_firewall_executor, which now resolves under security::active_response instead of security. I checked cargo check --all-targets on this commit and it fails before building the app with unresolved linux_* imports.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-06-03T09:32:59Z

+pub use imp::{
+    block_domain, block_process, block_remote, can_apply_quarantine_profile, can_block_domain,
+    can_isolate_network, can_kill_connection, can_modify_firewall, can_suspend_process,
+    extract_domain_target, extract_remote_target, freeze_autoruns, has_frozen_autoruns, is_blocked,
+    is_domain_blocked, is_process_blocked, is_process_suspended, isolate_machine, kill_connection,


Preserve the public active-response API exports

The new facade omits public functions that existing callers still use: src/security/response_rules.rs:598 calls active_response::apply_quarantine_profile, and src/autoruns.rs:13 calls active_response::revert_frozen_autoruns. Since the functions only exist inside private imp, cargo check --all-targets fails with unresolved function errors until these are re-exported or all callers are updated.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-06-03T09:32:59Z

+            ConnEvent::New(info) => {
+                self.add_conn_to_activity(info);
+                self.trim_history_buffers();
+                self.cached_activity_process_count = process_list::process_count(&self.activity);


Remove calls to missing process-list helpers

This event path now calls process_list::process_count, but src/ui/process_list.rs does not define or export such a function (only a CachedGroupView::process_count field exists). The same unresolved call is repeated for alerts and closed events, so any normal build of the UI fails at compile time before these handlers can run.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-06-03T09:32:59Z

+            ConnEvent::Closed {
+                pid,
+                proc_name,
+                local_addr,
+                remote_addr,


Match the current ConnEvent::Closed fields

ConnEvent::Closed is defined with { pid, local, remote, snapshot }, but this new handler destructures proc_name, local_addr, and remote_addr. I checked the enum in src/types.rs, and this pattern does not compile, so closed-connection handling currently blocks the entire UI build.

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-06-03T09:32:59Z

+                r"\\Temp\\",
+                r"\\AppData\\Local\\Temp\\",
+                r"\\AppData\\Roaming\\",
+                r"\\Downloads\\",
+                r"\\Public\\",


Restore single-backslash Windows path fragments

These defaults now contain doubled backslashes, but score.rs compares them with path_upper.contains(&frag.to_uppercase()) against normal Windows paths such as C:\Users\...\AppData\Local\Temp\..., which contain single separators. As a result, the default suspicious Windows drop locations no longer match and lose the intended +3 scoring signal for processes launched from Temp/AppData/Downloads/Public.

Useful? React with 👍 / 👎.

YMRYMR force-pushed the phase19-p5-ep2 branch from 48d94f7 to e8f915b Compare May 24, 2026 06:14

YMRYMR commented May 24, 2026

View reviewed changes

YMRYMR marked this pull request as ready for review May 25, 2026 11:42

YMRYMR marked this pull request as draft May 25, 2026 12:08

YMRYMR marked this pull request as ready for review May 25, 2026 20:41

chatgpt-codex-connector Bot reviewed May 25, 2026

View reviewed changes

Comment thread src/ui/mod.rs Outdated

Comment thread src/ui/mod.rs Outdated

Comment thread src/ui/tab_bar.rs

YMRYMR marked this pull request as draft May 25, 2026 21:12

fix active response schedule serialization

ca55541

YMRYMR added 2 commits June 1, 2026 21:14

active-response: avoid wrapper signature shadowing

8ab2395

active-response: format facade exports

4660140

YMRYMR added 2 commits June 3, 2026 11:18

Preserve latest alert for tray interactions and centralize scheduled-…

a4b4f72

…lockdown logic (#362) * Respect scheduled lockdown days * Handle overnight scheduled lockdown days * Clear Linux tray alert target on reset

Merge branch 'master' into phase19-p5-ep2

c629a49

YMRYMR marked this pull request as ready for review June 3, 2026 09:26

YMRYMR merged commit 9dd64c0 into master Jun 3, 2026
11 of 12 checks passed

chatgpt-codex-connector Bot reviewed Jun 3, 2026

View reviewed changes

Conversation

YMRYMR commented May 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Current branch scope

Current status

Next useful action

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR left a comment

Choose a reason for hiding this comment

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 24, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

chatgpt-codex-connector Bot commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 25, 2026

Uh oh!

YMRYMR commented May 31, 2026

Uh oh!

YMRYMR commented May 31, 2026

Uh oh!

YMRYMR commented May 31, 2026

Uh oh!

YMRYMR commented Jun 1, 2026

Uh oh!

YMRYMR commented Jun 1, 2026

Uh oh!

YMRYMR commented Jun 1, 2026

Uh oh!

YMRYMR commented Jun 1, 2026

Uh oh!

YMRYMR commented Jun 1, 2026

YMRYMR commented May 24, 2026 •

edited

Loading