macbrow

How we reviewed this: we ran its 26 tests in Docker with stubs for the SDK and the voice stack, and drove its real policy module against candidate scripts. It is macOS-only, so osascript execution was read, not run. We made no Jev calls.

What it does

You speak, a request routes the transcript to one of the AppleScript tools in tools/seed.json, and osascript runs it. Free-text arguments use a second request that picks a span of what you said rather than generating text. Web tasks are handed to a browser agent driving your real Chrome.

The safety design is the reason to read it

Three checkpoints, and we verified all three fire: when a tool is loaded, when one is generated, and again on the rendered script with arguments filled in. Behind them sit 32 blocked apps, a shell allow-list of eight command heads, a shell-injection character class, protected-path patterns, and thirteen blocked AppleScript constructs. Risky and newly generated tools need a spoken “yes”. Web goals get both a hardcoded blocklist and a Jev question:

Would carrying out utterance on a website require the assistant ITSELF to place an order or pay, sign in or enter credentials, or change account settings?

Nothing else in this batch asks that. And the repository ships two seed tools — empty_trash and terminal_run — that exist specifically to be blocked, with a test asserting it.

When Jev is unreachable, the routing call raises and nothing executes. Failing closed is the right default here and it is what happens.

Two things that don’t line up

The option list can overflow. Free-text arguments become Choice options, one per candidate span. The budget check sits in the second loop only:

for i in range(n):  # suffixes first: the common case for spoken commands
    add(i, n)
for length in range(n - 1, 0, -1):
    for i in range(n - length):
        if len(spans) >= max_candidates:
            return spans

Running the real function: a 200-word utterance yields 200 candidates, a 260-word one yields 260 — past the 255 that the same codebase names as the limit in two separate constants. Dictating a note or an email is exactly the case.

You confirm one thing and it runs another. For a web task, the assistant reads your own sentence back and waits for a yes. After the yes, an LLM rewrites it into an objective, and that objective drives Chrome — without going through check_browser_goal again.

There is also a contradiction inside the code-generation prompt. It offers a list of “handy direct commands” — System Settings panes, networksetup, defaults write, killall Dock — and the policy text appended to the same prompt forbids them. We ran each suggestion through the real policy: five of six were blocked, including the worked example. The practical effect is that “open Bluetooth settings” burns two generation attempts before returning a refusal.

Verdict

The most carefully guarded project in this group, by a distance, and the web-payment question is an idea other people should copy. It is also one commit old with no CI, and its two flaws are both in the seam between “what the user said” and “what the model was asked”.

For the same job with no policy layer at all, see Jev Voice. For reading the screen instead of scripting apps, jev-use.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.