Posts tagged with "agents"

Apple Announces Plan to Impose New Full Disk Access Controls on Mac Developers→

Today, on its developer blog, Apple announced plans to “…introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action.” The company says it’s doing so because of the dangers posed by AI agents.

According to Apple’s post:

Full Disk Access largely sidesteps these controls in order to allow backup apps to function properly on the Mac.

That’s nonsense. Looking at this MacBook Pro, only a handful of apps to which I’ve granted Full Disk Access are backup apps. Others include the Finder replacement Bloom, launchers like Alfred, the wonderful selection utility PopClip, Apple’s own Pixelmator Pro, Setapp, TestFlight, Unread, Supercharge, Madden NFL 27 Arcade Edition, Hazel, and many others. It’s a diverse selection of apps covering everything from Apple’s own apps to Mac utilities that are longtime favorites of MacStories readers, and even one Apple Arcade game.

What is valid is that AI agents pose risks if common-sense steps aren’t taken to limit their access to your data. So while the suggestion that Full Disk Access is just for backups doesn’t pass the smell test, Apple’s concerns about agents are well-founded.

The thing that bothers me about this post, though, is that it’s vague. On the one hand, it seems to suggest that users will simply have to jump through additional explicit hoops to grant Full Disk Access to their agents and other apps. On the other hand, claiming that Full Disk Access was designed solely for backup apps raises red flags that could signal that the company intends to restrict the kinds of apps that can use Full Disk Access. I sure hope not.

Even if you want nothing to do with AI agents, the changes that Apple is contemplating could impact a wide variety of the Mac apps you rely on every day. Apple needs to find a way enable reasonable customer protections without hamstringing the Mac’s utility.

Permalink

OpenAI’s Dots: A First Look

Source: OpenAI.

Source: OpenAI.

Earlier this week, I was at OpenAI’s annual DevDay conference where it launched Dots, a personal agent that lives inside the ChatGPT app. I set up my Dot and named it Puck after the mischievous sprite in Shakespeare’s A Midsummer Night’s Dream. In the days since then, I’ve found myself using Puck more and more. There are still rough edges, but I thought I’d share what’s working and what’s not, and how Dots are different from what’s already available in ChatGPT and Codex.

Dots are persistent, cloud-based agents that use the plugins and other tools you’ve connected to ChatGPT, after you allow them to do so. Your Dot has its own virtual Linux computer to assist you with your work. And at first, your Dot, which is depicted by a colorful character you can customize, doesn’t have access to anything else. However, as you give your Dot tasks that need access to other tools, it will ask for your permission to access other tools. The pacing of this initial interaction with your Dot is really well done. The requests felt natural and allowed me to get comfortable with expanding what I let Puck do without feeling like annoying interruptions.

Customizing my Dot.

Customizing my Dot.

Dots are available on mobile and desktop devices, and because they are cloud-based, your Dot’s chat is always synced between devices. But being a cloud-based agent has its downsides, too. Out of the box, your Dot can’t access your computer’s files and apps. That’s easily fixed by clicking or tapping on your Dot and granting it access to your Mac, so it can use the Mac alongside its own VM. As with Codex’s Remote feature, using a remote Mac with your Dot requires the ChatGPT app to be open on that Mac, too.

Read more

Frames CLI 1.5.0, Now with iPhone 18 Pro and (Experimental) iPhone Duo Support

The updated Frames CLI also supports proportional scaling for iPhone Duo.

The updated Frames CLI also supports proportional scaling for iPhone Duo.

The Frames CLI – the companion command line interface to my Apple Frames shortcut I released earlier this year – received a 1.5.0 update earlier today with two notable additions: iPhone 18 Pro frames, and experimental support for iPhone Duo screenshots in all poses.

As always, my shortcut and CLI are based on Apple’s official product bezels, which is why, as of today, there is no support for Apple Watch Series 12 and Ultra 4 yet (those frames haven’t been published by Apple). iPhone 18 Pro is the new default frame family for the two Pro and Pro Max screen sizes, and the CLI supports all the new device colors this year (Burgundy, Glacier, Silver, and Black).

iPhone 18 Pro in Burgundy.

iPhone 18 Pro in Burgundy.

iPhone Duo support is experimental. I obviously don’t have an iPhone Duo yet, but thanks to Opus 5.5, I was able to grab screenshots from the Xcode 27.1 Device Hub, verify them against Apple’s official assets, and test everything in the Frames CLI. It should work! The CLI – and, thanks to its skill, your agent of choice – supports framing screenshots taken on the inner and outer display, different poses, different rotation settings, as well as screen recordings.

If you’re a developer working on iPhone Duo apps, I think the updated Frames CLI should come in handy to automate the process of framing multiple screenshots and screen recordings. As before, you can take advantage of CLI features such as proportional scaling, merge mode, and batch mode, which should help you with your upcoming App Store submissions for the iPhone Duo.

The Frames CLI is free and open source, works with any agent, and is highly customizable. I’ll release an updated version of the Apple Frames shortcut once I can get my hands on an actual iPhone Duo next month (hopefully). Fingers crossed.

Hands-On with ChatGPT Work’s New Cloud Browser Feature

Yesterday, OpenAI introduced a new ChatGPT Work feature designed to let it navigate websites that require a login without revealing your credentials to the model.

Like a lot of people, I spend far too much time clicking around websites that require a login, looking at analytics and other data, checking whether new sponsors have been booked for our podcasts, and more. It’s a tedious but necessary part of my week that slows me down and takes me away from writing and other creative work. ChatGPT’s new Work feature is designed to handle that sort of work for you.

The feature works by signing into websites using a virtual, cloud-based computer. That separates the browsing session from any browsing session on your local computer, walling the agent’s computer use off from your open tabs, cookies, browsing history, passwords, and other data. Because the login and browsing happen in the cloud, that also means work can continue whether you close the ChatGPT app or power down your computer.

According to OpenAI, an additional review model checks the sign-in request and credential destination for signs of phishing or deception. ChatGPT Work then pauses while the user signs in. Credentials entered through its secure sign-in form go directly to the cloud browser and are not visible to the model. After the user authenticates, ChatGPT resumes its work.

OpenAI also explains that its cloud-based browser doesn’t store your username and password. Instead, it saves cookies that allow you to return to a previously authenticated session. If you don’t want to remain logged in, ChatGPT’s cloud browser settings allow you to clear browser data for individual websites or all sites.

Similar to other features in ChatGPT and Codex, users have choices when it comes to which sites ChatGPT Work can access. “Always ask” is the default, requiring the agent to check with the user before using a website, but the permission level can also be set to “Auto approve” after ChatGPT checks a site for relevancy and risk or “Always allow,” which OpenAI discourages. Individual websites can also be allowed or blocked. These settings control website access, but consequential actions require separate confirmation.

ChatGPT Work's browser control works best on a mobile device and with simple login systems.

ChatGPT Work’s browser control works best on a mobile device and with simple login systems.

I gave ChatGPT’s browser use a try and the results were mixed. I wasn’t able to get the feature to work at all using ChatGPT Work in Safari on my Mac. Some websites had security measures in place that prevented me from logging in. Other times, the cloud browser asked me to take over manually, but I was unable to do so because the UI was frozen or login panels didn’t appear.

Logging into a site with a CAPTCHA required manual intervention.

Logging into a site with a CAPTCHA required manual intervention.

I had better luck using my iPhone. On one site with a simple username and password system, a login sheet appeared. I entered my credentials, was logged in, and the agent navigated the site to answer my queries. On Apple’s affiliate link dashboard website, I had to take over the browser interaction manually to satisfy a CAPTCHA, which worked after several challenges. Once logged in, the agent pulled and analyzed the data I requested. Also, after I’d signed in to both of those sites on my iPhone, I remained logged in to ChatGPT’s cloud browser, which meant I could also use them from my Mac.

In its current form, the idea of having ChatGPT Work browse signed-in websites on your behalf is better than its implementation. If you can get logged in, having an agent collect and analyze things like analytics data is fantastic. However, getting past the initial login screen is still too frustrating. That said, I’ll be keeping a close eye on the feature, which is available on eligible plans depending on rollout and workspace settings, for future use collecting and analyzing data that would otherwise require a lot of clicking around.

The Utility App Flood Won’t Last

The App Store is evolving at a breakneck pace not seen since its earliest days. We saw the first glimmers of what was to come early in 2025, but it wasn’t until late last year that the tsunami of apps developed with the help of AI agents really took hold.

Since then, veteran developers are releasing new apps and updating existing ones faster than ever, and new developers are releasing their first apps in droves. Today, supply is dramatically up, demand is flat, and quality is seemingly simultaneously up and down, depending on where you look.

How these forces play out long-term is anyone’s guess, but it’s worth examining because, just as Federico’s link to Bryan Irace’s post about agentic coding tools foreshadowed the rise of tools like Codex and Claude Code, today’s trends are sparks that have the potential to become tomorrow’s App Store wildfires or simply fizzle out.

Utility apps are on the front lines of this change. The TechCrunch story I linked in April picked up on this trend:

Another interesting tidbit from Appfigures is that the Utilities app category moved up the top five chart.

If anything, the trend has accelerated in the months since.

It’s not surprising at all that utility apps have taken off. They’ve been a staple of new developers since long before agents came along. That’s because many are UI wrappers around command line tools. That isn’t a knock against the developers of those apps; most users don’t want to open Terminal to convert a video or audio file to another format using ffmpeg, for example. By building a great UI around command line tools, developers have made them far easier to use.

However, the relative simplicity and narrow scope of many utility apps have made them a natural fit for AI agents, too. That’s why the App Store (and my inbox) is deluged with Mac menu bar and single-screen iPhone and iPad utility apps.

On the one hand, the abundance of utilities has been great for users. More choice means you’re more likely to find the app that perfectly fits your needs.

On the other hand, though, I don’t think what’s happening in the category is sustainable and expect to see it dramatically shift again in the coming months. As we’ve seen from reporting by The New York Times, app supply is outstripping demand by orders of magnitude, which will drive down prices. That alone is likely to cause the utility app market to shrink. But there’s more to it than that.

Remember, the demand shifts that The New York Times reported, based on Sensor Tower numbers, are for the entire App Store, where download numbers have grown 2-3% this year and last. I expect utility downloads to actually shrink in the coming months – again, because of agents. Utilities, especially simple ones, are exactly the sorts of apps that are becoming trivially easy for power users – the very users these utilities are made for – to create themselves. From frontier labs‘ model improvements to a growing number of app-building tools from those same labs and third parties, it’s never been easier to build a web or native app yourself.

And although I agree with people, like Nilay Patel, who say the notion that everyone will build their own software is overblown, the utility market is different. Your average person is not downloading apps to adjust the frame rate and file format of a video or downloading YouTube videos to watch later. But those are exactly the sort of things that people who are using agents are doing with them, whether they’re having an agent do those things directly via a command line tool in an app like Codex or Claude Code or building an app to do the same thing. That’s going to put even more pressure on the category.

That said, I think there will always be a cohort of users who would rather pay for an app than build it themselves, so I’m not predicting the demise of utilities in general – just the end of today’s frothy market. I also think there remains a place for simple utilities that solve hard problems with clever solutions. Not every utility is a UI wrapper for a terminal command. Plenty of apps feature original solutions or thoughtful and unconventional remixes of disparate tools.

Utilities aren’t going away, but just like other App Store deluges, the trend will recede. It’s just that this time, it’s likely to flip faster than usual.

App Store Chaos→

Kalley Huang, writing for The New York Times about apps written with the help of AI agents that are flooding the App Store:

But as with many things A.I., just because something is easy to build doesn’t mean people will use it. It is not clear if vibecoding is breathing new life into the App Store or just cluttering it.

Last year, the number of new apps released in the App Store grew 30 percent to about 600,000, according to estimates by Sensor Tower, an app analytics firm. In the first half of this year, new apps doubled to about 560,000.

Now, Sensor Tower metrics should always be taken with a grain of salt. They don’t have direct access to Apple’s sales data, so they’re extrapolating from incomplete data that they collect themselves. That said, I think it’s fair to take their numbers as broadly representative of sales trends over time, and the story they tell, as reported by Huang, is interesting.

Based on Sensor Tower’s numbers, the total number of App Store releases peaked in 2016 at 890,000, hit a low of 420,000 in 2022, and this year, is on pace to pass 2016’s peak by a healthy margin. But app releases don’t equate to downloads, let alone sales. According to Huang’s reporting, downloads increased 3% in 2025 and 2% in the first half of 2026, far lower than the growth of new releases.

All of this tracks closely with what we’ve seen at MacStories. One subtle trend I’d add is that whereas for years most developers contacted us before they released an app, a lot of new developers are doing so after their apps are on the App Store. I suspect what I’m seeing is a new generation of developers learning the hard discoverability lessons of the App Store for the first time because when I check out these apps, they rarely have any App Store reviews.

The upshot of all these statistics and trends is App Store chaos of a magnitude that we haven’t seen in a long time. It’s a little like the App Store gold rush of the early days, but without the gold. Discoverability has gone from bad to worse, and the supply of apps is off the charts compared to the demand. With download numbers barely creeping up, the flood of new apps is making selling on the App Store harder for everyone.

Yet, it’s exactly this sort of chaotic disruption that leads to exciting new apps. And, it’s tools like Codex and Claude Code that empower and democratize app development, allowing people who would never have built an app to see their ideas become a reality. Those are things I love to see.

There’s no doubt that the App Store is out of whack thanks to agent-assisted coding, but like any market it will find its equilibrium again. In the meantime, it’s never been a better time to be a fan of apps because while a lot of those record numbers are comprised of mediocre apps, there are hidden gems, and we’re on the hunt for them.

Permalink

Safari’s New MCP Server Is Great for Agents→

Saron Yitbarek, writing on the WebKit blog:

In Safari Technology Preview 247, we’re introducing the Safari MCP server — a Model Context Protocol server for web developers that makes your web development and debugging workflow faster and more powerful. We know agents are increasingly integral to the coding process and the Safari MCP server gives your agent the ability to know how your code actually renders in the browser by connecting it to a Safari browser window.

Any MCP-compatible client can connect to the Safari MCP server. By connecting your agent to a Safari browser window, your agent can emulate what your users experience, giving it the information it needs to debug more autonomously, like access to the DOM, network requests, screenshots, and console output.

Importantly:

The Safari MCP server runs entirely on your local machine and makes no network calls of its own. It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity). When it captures page content, screenshots, or console logs, that data goes directly to the agent you’re running — not to Apple. What happens to that data from there depends on the agent and model you’re using. As with any agent you give access to your browser, only use ones you trust.

For the past few months, I’ve been using Google Chrome on my MacBook Pro and Mac Studio not because I like the browser (in fact, I really dislike Chrome’s text rendering and UI), but simply because it was the best option for agents. In Codex specifically, between Playwright, Chrome Dev Tools, and OpenAI’s own Chrome extension, I could kick off research tasks (such as vacation planning and booking a hotel) that involved a browser directly from my iPhone, letting Codex drive the research on my remote Mac.

Safari in Codex.

Safari in Codex.

Now, thanks to Safari’s new MCP server, I no longer have to use Chrome on desktop and can return to a unified browser setup across all my devices. Even better: it actually looks like Apple shipped the most ergonomic browser MCP for agents to date. The MCP server has dedicated tools for page extraction (including getting webpages as Markdown, based on WebKit’s own conversion pipeline), evaluating JavaScript, DOM interactions (clicking, scrolling, resizing the viewport for mobile screens, etc.), taking screenshots, and more. I set this up immediately in Codex, and I also asked Codex about comparing Safari’s MCP to its own Chrome extension and the older Playwright. The verdict: although Chrome has a richer API with Chrome Dev Tools when it comes to network requests, Codex actually preferred Apple’s leaner, more direct approach for letting an agent drive and debug a browser.

I’m really happy to see folks at Apple embrace agentic tools: between the new MCP capabilities of Xcode and now this, it looks like Apple’s software (on the Mac, of course) is becoming more and more approachable by people who are working in new ways thanks to agents. Whether you’re a web developer or tinkerer, I highly recommend checking out what Apple has released in Safari Technology Preview. More of this, please.

Permalink

Headless Macs and Hamstrung iPads

My Codex setup.

My Codex setup.

In the current era of coding agents becoming productivity assistants, iPadOS’ limitations are no longer defined by the lack of desktop-class multitasking or access to external peripherals. A new class of iPadOS shortcomings looms large on the horizon: the iPad’s app sandboxing and the absence of an open filesystem have relegated it to acting as a remote control for agents.

Read more

RemCTL 1.0.5, Now with Support for All-Day Reminders and Task Assignments→

RemCTL 1.0.5 with support for task assignments and all-day reminders.

RemCTL 1.0.5 with support for task assignments and all-day reminders.

I wanted to share a quick update to RemCTL, my CLI for Reminders that I released last week, which brings almost every Reminders feature to your agent or terminal of choice.

As it turns out, I forgot to support two more Reminders-exclusive (i.e. not available to third-party clients) functionalities in the initial version: all-day reminders and the ability to assign a reminder to another person in a shared list. The former is the feature that lets you enter a task with a due date such as “Tuesday” but without a due time;. those tasks can now be properly read and written by RemCTL.

Additionally, while RemCTL cannot share lists with iCloud (it requires a private Apple entitlement – same reason why the CLI cannot share a template via iCloud), it can now read and create task assignments from an already-shared Reminders list. In a nice touch, you can even lookup assignees by name, email address, or phone number.

You can find a detailed changelog of the latest release here. As always, the best way to update the CLI is to simply ask your agent to pull the latest version and update its installed skill to match the most recent version from the repo.

Permalink