fix(overlay): seed display info from launch args instead of racing IPC by pango07 · Pull Request #7 · pango07/flicky

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

pango07 · 2026-08-10T18:31:02Z

Found while looking into #5.

the bug

createOverlayWindow pushed display-info on a once('did-finish-load') handler (windows.ts:96), but OverlayApp attaches its listener inside a useEffect (OverlayApp.tsx:197). Nothing orders those two. When the send lands first the message is dropped, and because it's once it never comes again, so displayRef.current stays null for the lifetime of the window.

Every cursor position then falls through to the else branch:

}else{setIsCursorOnThisDisplay(true);setCursorPos(pos);// global screen coords treated as display-local}

That happens to be correct on a single display at origin (0,0), which is why it hasn't bitten anyone yet. On a second monitor, or any display with a non-zero origin, the companion cursor renders at the wrong offset. onElementDetected has the same dependency at OverlayApp.tsx:230, so pointing targets land wrong too.

the fix

Pass the display through webPreferences.additionalArguments, so the preload parses it out of process.argv and the renderer has its coordinate space synchronously on mount. No ordering to get wrong.

The IPC push stays for reloads and is now on rather than once, since the argv value is only correct for the first load.

DisplayInfo and the arg prefix moved into shared/types.ts (the shape was inlined in three places)
new window.flicky.getDisplayInfo(), returns null in non-overlay windows
onDisplayInfo keeps working, now typed off the shared interface

testing

npm run typecheck passes. npm run lint fails on master too, unrelated: eslint 9 wants a flat eslint.config.js and the repo doesn't have one.

Not runtime-tested, I don't have a display here. Worth a quick check on a multi-monitor setup that the companion still tracks correctly on the non-primary display.

note

This is not the mic bug in #5, that's a separate chain I commented on in the issue. This is the second symptom the reporter mentioned (cursor not trailing), though I suspect their specific case is Wayland's getCursorScreenPoint() rather than this. Worth fixing either way.

Generated by Claude Code

createOverlayWindow pushed display-info on a once('did-finish-load') handler, but OverlayApp attaches its listener inside a useEffect. When the send landed first the message was dropped and displayRef stayed null for the lifetime of the window, so cursor positions fell through to the unmapped branch that treats global screen coordinates as display-local. That happens to be correct on a single display at origin (0,0), which is why it went unnoticed, and wrong everywhere else. Pass the display through webPreferences.additionalArguments so the preload can parse it synchronously and the renderer has its coordinate space before the first cursor-position message arrives. The IPC push stays for reloads, and is now `on` rather than `once` since the argv value is only correct for the first load. Refs #5

The comment claimed the argv value was only correct for the first load. It isn't: a reload re-executes the preload in the same process with the same argv, so the re-push sends an identical snapshot. It's redundancy, not an update path, and bounds changes don't flow through it at all — rebuildOverlays destroys and recreates the window instead. Say so. Also warn instead of silently returning null when the launch argument fails to parse, since that failure would otherwise reproduce the exact symptom this change exists to fix, and note why plain JSON in argv is safe here (all-numeric fields, so no spaces for Windows to split on).

vercel · 2026-08-10T19:28:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
flicky	Ignored	Preview	Aug 10, 2026 7:28pm

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

claude added 2 commits August 10, 2026 18:29

pango07 merged commit 533432e into masterAug 14, 2026
6 checks passed

Conversation

pango07 commented Aug 10, 2026

the bug

the fix

testing

note

Uh oh!

vercelBot commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

pango07 commented Aug 10, 2026

the bug

the fix

testing

note

Uh oh!

vercelBot commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

pango07 commented Aug 10, 2026

the bug

the fix

testing

note

Uh oh!

vercelBot commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

pango07 commented Aug 10, 2026

the bug

the fix

testing

note

Uh oh!

vercelBot commented Aug 10, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

pango07 commented Aug 10, 2026

the bug

the fix

vercelBot commented Aug 10, 2026•
edited
Loading

vercelBot commented Aug 10, 2026•
edited
Loading

vercelBot commented Aug 10, 2026•
edited
Loading

vercelBot commented Aug 10, 2026•
edited
Loading

vercelBot commented Aug 10, 2026•
edited
Loading

vercelBot commented Aug 10, 2026•
edited
Loading