Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/logging/dedup.ts`:
- Around line 19-25: The makeKey method can throw when JSON.stringify is given
circular or non-serializable values; update makeKey in src/logging/dedup.ts to
safely serialize each arg instead of calling JSON.stringify directly: for each
arg in the args array attempt JSON.stringify in a try/catch and on failure fall
back to a safe, non-throwing representation (e.g., use String(a), a.toString(),
or util.inspect(a) with a fallback for BigInt), ensuring no exceptions propagate
from makeKey; preserve the existing replacements (.replace(/\b\d{4,}\b/g, '#')
and .replace(/\b\d+\.\d+\b/g, '#')) and continue returning `${level}|${text}`.
- Around line 12-13: The deduplication state is shared via the single field
lastKey causing IPC and file transport to interfere; add two separate fields
(e.g., lastIpcKey and lastFileKey) on the LogDeduplicator class, initialize them
like the current lastKey, update shouldLog(...) to read/update lastIpcKey only,
and update createFileHook(...) (and any file-write-related helpers) to
read/update lastFileKey only so IPC and file deduplication are isolated.

In `@src/logging/index.ts`:
- Around line 148-173: flushErrorJsonl currently appends errorJsonlBuffer using
fs.promises.appendFile without awaiting, and the before-quit handler invokes
flushErrorJsonl synchronously so logs can be lost on fast shutdown; modify
flushErrorJsonl (and any caller such as the before-quit handler) to perform a
synchronous write path during shutdown: expose a new synchronous flush path
inside flushErrorJsonl that uses fs.existsSync/fs.statSync and fs.writeFileSync
or fs.appendFileSync to truncate and append to errorJsonlPath when called with a
shutdown flag (or call a new flushErrorJsonlSync helper), ensure it handles
MAX_ERROR_LOG_SIZE truncation the same way, and update the before-quit handler
to call the synchronous variant (flushErrorJsonlSync or flushErrorJsonl(true))
so the process writes logs to disk before exit.

In `@src/logging/privacy.ts`:
- Around line 148-157: The current replacer in the IP redaction logic (pattern:
... , replacer: (m) => { ... }) incorrectly treats all 172.* addresses as
private; update the condition so only 172.16.0.0–172.31.255.255 are exempted.
Replace the m.startsWith('172.') check with a precise test (e.g. parse the
second octet with m.split('.') and ensure parseInt(octets[1]) is between 16 and
31 inclusive, or use a regex like /^172\.(1[6-9]|2[0-9]|3[01])\./) inside the
replacer so public 172.x.x.x addresses are masked. Ensure you keep existing
exemptions (127.0.0.1, 0.0.0.0, 192.168.*, 10.*) and only alter the 172 check.

In `@src/logViewerWindow/ipc.ts`:
- Around line 325-356: The IPC handler should validate and sanitize
options.fromByte before numeric ops: in the async handler that reads options ({
fromByte: number; filePath?: string }), check that options.fromByte is a finite
integer (e.g., typeof === 'number' && Number.isFinite(...) &&
Number.isInteger(...)) or coerce it safely (Number(...) and floor) and fallback
to 0 if invalid, then use that sanitized value when computing fromByte =
Math.max(0, Math.min(sanitizedFromByte, stats.size)); this prevents NaN being
passed to fs.createReadStream or other downstream APIs.

---

Outside diff comments:
In `@src/logging/index.ts`:
- Around line 396-411: The IPC console-log handler currently trusts
renderer-supplied webContentsId and serverUrl for rate-limiting and attribution;
update the handler to use event.sender.id as the rate-limit key (replace uses of
webContentsId when accessing ipcRateLimit and counting against
MAX_IPC_MESSAGES_PER_SECOND) and derive the origin URL from the authenticated
sender (use senderWebContents.getURL() after computing senderWebContents from
event.sender or webContents.fromId) instead of using the renderer-supplied
serverUrl; adjust any logic that falls back to webContents.fromId(...) so it
always treats event.sender as the authoritative source for id and URL.

---

Nitpick comments:
In `@src/ipc/channels.ts`:
- Around line 98-122: Channel contract missing for the server-tag channel: add
an entry for 'log-viewer-window/get-server-tag' into ChannelToArgsMap with the
correct request/response shape so TypeScript checks cover preload.ts; for
example, add a mapping from () => { success: boolean; tag?: string; error?:
string } under the ChannelToArgsMap object to mirror other log-viewer-window
contracts and ensure compile-time verification.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/logging/dedup.ts`:
- Around line 69-72: The dedup key generation currently uses
message.data?.map(String).join(' ') which converts non-string structured
payloads to "[object Object]" and can erroneously suppress distinct logs; update
the logic that builds text (used in key and compared to this.lastFileKey) to
serialize non-string items deterministically (e.g., if item is a string keep it,
otherwise JSON.stringify with a safe fallback for circular refs or use
util.inspect) so structured objects produce meaningful tokens; modify the code
around message.data, text and key (references: message.data, text, key,
this.lastFileKey) to use the safe serialization helper and ensure the rest of
the key normalization (digit masking) stays the same.

In `@src/logging/privacy.ts`:
- Around line 279-283: redactObject(rest, ...) can return a non-object sentinel
(e.g. string), so do not spread its result unguarded; instead assign const
redactedRest = redactObject(rest, depth + 1, seen) and check its type: if typeof
redactedRest === 'object' && redactedRest !== null return { ...redactedRest,
state: '[Redux State Redacted]' }, otherwise return a stable object that
preserves the state key and carries the sentinel (for example return {
_redacted: redactedRest, state: '[Redux State Redacted]' }) so callers never
receive a corrupted shape; update the code around redactObject/rest accordingly.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/logging/privacy.ts`:
- Around line 263-265: The depth check currently uses "if (depth > 10) return
'[Nested Object Redacted]';" which allows processing at depth 10 instead of
redacting at that limit; change the condition to "if (depth >= 10) return
'[Nested Object Redacted]';" (update the check that references the variable
depth and the redaction string '[Nested Object Redacted]') so the function
enforces a maximum depth of 10.
- Around line 104-106: The regex replacer currently preserves the captured
username because the replacer function only accepts (_m, proto, user) and then
injects user into the output; update the replacer to accept the password capture
as a third parameter (e.g., (_m, proto, user, pass)) and redact the username as
well as the password in the returned string (for example return
`${proto}[REDACTED]:[REDACTED]@` or a masked username) so both the username and
password captures from the pattern /(https?:\/\/)([^:]+):([^@]+)@/gi are
removed.