Problem
sendControl (and the corresponding openshock-send-control IPC handler at main/index.ts:1872) accept whatever intensity and duration the caller hands it and forwards them directly to OpenShock's /2/shockers/control endpoint with no upper bound and no lower bound. The renderer is the only guardrail, and the composable exposes sendControl([{ id, type, intensity, duration }]) for arbitrary input. With physical shock devices wired to a person, an unfired or duplicated trigger (e.g. an OSC parameter that gets stuck at max from a chatbox trigger, an avatar change, or a buggy force-feedback loop) can apply shocks outside the per-shocker safe range.
Evidence
main/containers/openshock/openshock.ts:270-275
async sendControl(
shocks: Array<{ id: string; type: 'Shock' | 'Vibrate' | 'Sound' | 'Stop'; intensity?: number; duration?: number }>
): Promise<void> {
await this.fetchApi(API_PATHS.SHOCKERS_CONTROL, 'POST', { shocks, customName: 'ARC-Client' })
debug.info(`OpenShock: Control sent to ${shocks.length} shocker(s)`)
}
main/index.ts:1872
ipcMain.handle('openshock-send-control', async (_event, shocks: any[]) => {File: main/containers/openshock/openshock.ts:270 in ComfyChloe/ARC-Client.
Suggested fix
Cap at the highest per-shocker safe cap: clamp intensity to [0, 100] and duration to [100, shockerLimits.maxDurationMs || 10000] ms, drop entries that exceed either limit, and apply a per-second (and per-shocker) request budget in both the renderer composable and the main-process handler so a runaway OSC trigger cannot stack commands. Surface the caps in the create-share-link and OpenShock page so users understand what their panel allows.
Problem
sendControl(and the correspondingopenshock-send-controlIPC handler atmain/index.ts:1872) accept whateverintensityanddurationthe caller hands it and forwards them directly to OpenShock's/2/shockers/controlendpoint with no upper bound and no lower bound. The renderer is the only guardrail, and the composable exposessendControl([{ id, type, intensity, duration }])for arbitrary input. With physical shock devices wired to a person, an unfired or duplicated trigger (e.g. an OSC parameter that gets stuck at max from a chatbox trigger, an avatar change, or a buggy force-feedback loop) can apply shocks outside the per-shocker safe range.Evidence
File:
main/containers/openshock/openshock.ts:270inComfyChloe/ARC-Client.Suggested fix
Cap at the highest per-shocker safe cap: clamp intensity to
[0, 100]and duration to[100, shockerLimits.maxDurationMs || 10000]ms, drop entries that exceed either limit, and apply a per-second (and per-shocker) request budget in both the renderer composable and the main-process handler so a runaway OSC trigger cannot stack commands. Surface the caps in the create-share-link and OpenShock page so users understand what their panel allows.