<p>"The button is too low."</p><p>Which button? On which page? Too low compared to what? If you've ever tried to describe a visual bug to a coding agent in words, you know the dance: the blue one, no, the other blue one, in the header, the right-hand side. You end up writing a paragraph to say what a single click could have said.</p><p>Workspace 0.4.0 is a small release with a big theme: less guessing, and more say over what your agents do. Three things, all of them things we kept wishing for while using it ourselves.</p><h2>Point at an element</h2><p>Since 0.2 there's a browser in the tools panel (&lt;kbd&gt;⇧&lt;/kbd&gt;&lt;kbd&gt;⌘&lt;/kbd&gt;&lt;kbd&gt;B&lt;/kbd&gt;) for the app you're building. In 0.4.0 it grows a target button in the toolbar.</p><p>Press it, then click the thing on the page: a button that sits too low, a heading in the wrong colour. While you're picking, the element under the pointer is outlined, and the page doesn't react to your clicks, so you can't accidentally submit the form you're trying to point at. &lt;kbd&gt;Esc&lt;/kbd&gt;, or the button again, stops.</p><p>Then something nice happens. Your message gets the element attached to it, as a picture of it with a little of its surroundings, plus its details: a selector that matches only that element, its position and size, its text, its computed styles (layout, spacing, colours, fonts), and its HTML.</p><p>So instead of the paragraph, you write:</p><blockquote><p>This button sits too low.</p></blockquote><p>…and send. The agent doesn't have to guess which button, because it has the selector. It doesn't have to guess how it's too low, because it has the spacing and layout styles. And it can see the picture, so it knows what you were looking at.</p><p>A few practical notes from the docs. It works on any page, since it only adds to the message you send. Password field values are left out. And it plays well with what 0.3 added: the chip above the message box that offers new console errors with one click, and the pictures of the page from before and after each turn.</p><p>Put together, a front-end loop looks like this: the agent changes the CSS, you see the before and after pictures under the turn, the heading is now the wrong colour, you point at it, write "wrong colour", and send. No console, no screenshots saved to your desktop, no paragraph.</p><h2>Agents ask before changing another thread</h2><p>This one is about trust.</p><p>Since 0.2.2, the agent gateway lets agents work with your other threads: list them, read them, create them, steer them. It's powerful, and we've been careful about what it can do. It listens only on <code>127.0.0.1</code>, it requires a token, and every call lands in an audit log.</p><p>0.4.0 adds a question. An agent may read any thread, but the first time it messages, stops, renames or archives another thread, Elyra asks you:</p><ul><li><p><strong>Don't allow</strong></p></li><li><p><strong>Allow once</strong></p></li><li><p><strong>Always allow</strong></p></li></ul><p><strong>Always</strong> remembers that particular pair of threads. You can see how many are remembered, and forget them, in <strong>Settings → Agents &amp; MCP → Agents changing other threads</strong>.</p><p>Imagine an agent working on the API thread decides the frontend thread should hear about a changed response format. Previously that was a tool call under the thread's permission mode. Now, the first time it reaches into another thread to say so, you get to say yes or no. Say yes once and it happens. Say always, and these two threads can talk without asking again.</p><p>Two details that keep it from being annoying. Threads an agent starts itself with <code>create_thread</code> are its own, so it isn't asked about those. And paired clients such as Claude Desktop aren't asked either: pairing them was the permission.</p><p>The point isn't to slow agents down. It's that "the agent can change my other threads" should be a decision you made, not a default you inherited.</p><h2>Updates that wait for your agents</h2><p>You get a notification: a new version is ready. You click it to restart. But three of your agents are in the middle of a long refactor.</p><p>Before 0.4.0, agents still working were stopped first (after asking) and could be resumed. That worked, but it meant choosing between "update now" and "don't interrupt the work."</p><p>Now you get both options. If agents are still working, you can choose:</p><ul><li><p><strong>Restart when they finish:</strong> waits, then restarts by itself once no turn is running.</p></li><li><p><strong>Restart now:</strong> stops them, and each thread can be resumed after the update.</p></li></ul><p>And if you don't click anything, the update installs the next time you quit, as before. It's a small thing, but it removes the little hesitation every time the notification appears. You can say "yes, update, just not in the middle of that."</p><h2>Why these three</h2><p>They share a thought: an agent should be able to do a lot, and you should be able to see and steer it cheaply.</p><p>Pointing at an element makes it cheap to tell the agent exactly what you mean. Asking before changing another thread makes it cheap to keep control of the one thing that reaches beyond a single task. Waiting for agents before an update makes it cheap to stay current without losing work.</p><h2>Try it</h2><p>Workspace 0.4.0 is out now. If you already have it, the app checks GitHub at launch and installs the new build only if its checksum matches, it's signed by the same Developer ID team as your copy, and Gatekeeper accepts it. And now it'll wait for your agents if you ask it to.</p><p>New here? It's a signed, notarized DMG for macOS 12 or later on Apple silicon, free and open source. Download it at <a target="_blank" rel="noopener noreferrer nofollow" href="https://elyracode.com/workspace">elyracode.com/workspace</a>, and see the full notes at <a target="_blank" rel="noopener noreferrer nofollow" href="https://elyracode.com/docs/workspace/changelog">elyracode.com/docs/workspace/changelog</a>.</p>