# Add a Launch at Login Setting to an Electron App from a Linear Issue

Yes. An agent reads the issue, adds a launch at login toggle to your Electron app over IPC with tests, and opens a pull request that links back to it.

[Run this on Rush](https://cloud.getrush.ai/run/add-auto-launch-setting/electron/), in a Project that has your repository.

## What the agent does

The agent starts by reading how the repository is wired before touching the setting. In electron-react-boilerplate the main process lives in src/main/main.ts, compiled by electron-vite to release/app/dist/main/main.js, the preload script src/main/preload.ts exposes a typed window.electron bridge through contextBridge with a single ipc-example channel, and src/renderer/App.tsx renders one react-router-dom route. package.json pins electron ^44.4.0 and react ^19.3.0, the test script is jest, and npm run package runs npm run build followed by electron-builder build --publish never.

Adding the setting means crossing the process boundary in three files. In src/main/main.ts the agent registers two ipcMain.handle listeners for a new launch-at-login channel: one returns app.getLoginItemSettings() when the window loads, the other calls app.setLoginItemSettings({ openAtLogin: value }) when the toggle changes. In src/main/preload.ts it extends the electronHandler with typed invoke-based get and set methods for that channel and adds the channel name to the Channels union. src/renderer/preload.d.ts picks the new shape up on its own because it re-exports the ElectronHandler type.

In the renderer the agent adds a toggle rather than a new screen. A component in src/renderer renders a checkbox for launching at login, calls window.electron.launchAtLogin.get() on mount so the checkbox shows the real current state, and calls the set method on change, with its styles beside the existing App.css. The component never imports electron itself; the bridge is the only path to the main process, and its type comes from the global declaration the repository already ships.

Tests follow the two patterns the repository already has. src/__tests__/App.test.tsx renders with @testing-library/react under jsdom, so the agent adds a test that the toggle renders checked when the bridge reports openAtLogin is true. For main-process logic it copies src/__tests__/updates.test.ts, which runs in a node environment and stubs the electron module with jest.mock; the new test mocks app.getLoginItemSettings and app.setLoginItemSettings and asserts the handlers read and write them. It then runs npm test and npm run package in the sandbox so the branch is proven before the pull request opens, and names the issue in the pull request body.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Linear issue labeled agent says: \"Add a Launch at Login Setting to an Electron App. Add a settings toggle in the renderer that calls app.setLoginItemSettings in the main process over IPC and shows the current state on load.\" Do the work in this repository, add tests for it, run npm test and npm run package, and open a pull request that links back to the issue.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request on a new branch that names the Linear issue. The diff touches the files that carry the feature: src/main/main.ts with the two handler registrations, src/main/preload.ts with the typed bridge methods, a new or changed renderer component for the toggle, and test files under src/__tests__ that follow the App and updates patterns. The repository's own CI, .github/workflows/test.yml, runs npm run package, npm run lint, tsc --noEmit and npm test on macOS, Windows and Ubuntu, so the pull request arrives with checks on it.

A reviewer checks three things before merging. The preload bridge must go through ipcRenderer.invoke on a typed channel, not a raw send the renderer cannot await. The get handler must read app.getLoginItemSettings() so the checkbox shows the real state on load rather than a hardcoded default. And the tests must stub the electron module the way updates.test.ts does, since the real app object does not exist under jsdom. The transcript at GET /o/{org}/sessions/{id}/messages keeps every command and its output, including the npm test and npm run package runs, so the review can see what passed before the pull request opened.

## Run it on every labeled Linear issue

Point a Linear webhook at your server for issue.labeled events on the agent label. When one arrives, your server sends this same request with the issue text as input; the run clones the repository through the Rush GitHub App, which has to be installed on it because resources names it, and opens the pull request that links back. Labeling five issues starts five independent runs, each in its own sandbox with its own branch.

Set a webhook URL on the API key and Rush POSTs run.completed or run.failed with the session URL when each run finishes, so your server can comment the pull request link back on the issue. A key runs at most max_concurrent sessions at once, 4 by default, and answers 429 past that. Send an Idempotency-Key header so a retried webhook delivery does not start the same run twice.

## Why run it on Rush?

Doing this on a laptop means the Electron checkout, its node_modules and a display for packaging sit on your machine while the work runs. On Rush the run gets its own sandbox with its own clone: it installs dependencies with the npm version package.json requires, node 24 and npm 10 or newer, runs npm test and npm run package there, and pushes the branch. Nothing runs on your desktop and the run continues if you close the laptop.

The result is reviewable rather than asserted. The pull request carries the diff, and the repository's own CI matrix is the check. The session's transcript keeps every tool call with its command output, so you can watch exactly how the toggle crossed the IPC boundary and what the test and packaging runs printed. Because each labeled issue is its own run, a triage board becomes a queue of pull requests a person merges or sends back, with no one starting the work by hand.

## Frequently asked questions

### Which files does the change touch?

src/main/main.ts gains the two ipcMain.handle registrations around app.setLoginItemSettings and app.getLoginItemSettings. src/main/preload.ts gains the typed invoke methods and the new channel name in the Channels union. A renderer component renders the toggle, and new tests under src/__tests__ cover both sides. Every change is in the pull request diff.

### How does the toggle reach the main process?

Only through the preload bridge. The renderer calls a typed window.electron.launchAtLogin method, which maps to ipcRenderer.invoke on the new channel, and the main process answers with the current state or applies the new one. The renderer never imports electron directly, which is what the contextBridge sandbox is for.

### Do the tests boot a real Electron app?

No. The renderer test renders with @testing-library/react under jsdom, the environment jest.config.js sets. The main-process test stubs the electron module with jest.mock, the pattern updates.test.ts already uses, and asserts the handlers call the mocked app methods. npm run package then builds with electron-vite and packages with electron-builder, which proves the compiled bundle works.

### How is the pull request linked to the issue?

The pull request body names the issue identifier, and the branch references it, so the issue shows the pull request on its timeline in Linear or GitHub. The repository's test.yml workflow runs npm run package, lint, tsc --noEmit and npm test on three operating systems, so the checks on the pull request are the repository's own.

### My Electron app is not this boilerplate. Does it still work?

Yes, because the agent reads your repository first instead of assuming its layout. It finds your main entry, preload script and renderer root, then applies the same shape: a toggle in the renderer, an invoke-based get and set across IPC, state read on load, and tests next to yours. Name your entry files in the prompt if they are unusual.