DEV Community: GoodBarber

Old apps still call home

Dominique Siacci — Tue, 27 Oct 2026 14:20:56 +0000

Somewhere this morning, a phone opened an app that was built on our platform years ago. Its owner hasn't touched it in a long time. The person holding the phone never updated the app, or no update ever came, because nobody rebuilt it. The app started, asked our servers for its content, and got an answer it could read.

That only works because we still answer in the format the app was built for, even though our own formats have changed since.

The client you can't upgrade

Most advice on API versioning assumes one of two things about your clients: you control them, or you can retire them. A web app ships its own front end, so a breaking change is a coordinated deploy. A public API has a deprecation calendar, a sunset header, an email to the developers. Either way, at some point the old client stops being your problem.

A platform that publishes apps can do neither. The client is a binary on someone's phone. It was built on a day we didn't choose, and its next version, if there is one, comes from the store on a day we don't choose either. We don't force updates: an app that works keeps working, and nobody is asked to rebuild because our own formats changed. I've written about what that promise costs when the world around an app moves. This piece is about what it costs when we move.

And we do move. The engine gets new generations, our answers change shape, newer endpoints get a cleaner design than the old ones. Meanwhile, the apps published before each of those changes are still installed, still speaking the dialect they were built with, and still expecting an answer in it.

Dialects, side by side

When a new generation of the engine arrived, the old one didn't move. It kept its paths, its file layout and the shape of its answers. The new generation got its own tree next to it. The same servers answer both today, and an app built against the old generation is served the old generation, for as long as it's around.

A phone only gets the new generation with a new build of the app, installed from the store. Until then, it runs the old binary, and the app's answers in the old tree are still there for it: they aren't deleted, and they keep the shape that binary was built for. The new build reads its own answers, written next to them in the new shape.

Why not just force the update?

Forcing an update would move the work onto other people. An update we force is a rebuild the owner has to run, a submission they have to make again, and a download the user has to accept: two parties doing work so that we can retire one code path. Multiplied by every app on the platform, that's a lot of work on their side to save some on ours.

Keeping a dialect alive is work we do once, on our side, instead of asking every owner for a rebuild. It has a cost: we keep testing every old path, and we keep maintaining a reader for every format we still serve. It's the same reasoning that keeps a link printed on a flyer years ago opening the right screen in today's version of the app.

There's a limit, and it comes from outside. When a store, an operating system or a certificate retires something an old binary relies on, that app needs a rebuild, whatever our servers answer.

Still asking

Some of the apps calling our servers this morning haven't been rebuilt in years, and people still use them. Keeping them working means keeping their vocabulary: answering in the words they were built with, and retiring nothing while someone still depends on it.

If you run an API for clients you can't upgrade, how do you decide when an old version can finally stop answering?

Agents don't mind the brackets: can AI bring back demanding languages?

Mathieu Poli — Tue, 27 Oct 2026 13:00:00 +0000

Rust asked a lot of the people who wrote it. We're no longer the ones writing it.

I had this hunch from reading what people write about Rust and agents: the languages we found too demanding might come back, because we're no longer the ones paying their price.

That suited me: I started out as an Objective-C developer, and I've always kept a soft spot for this neglected language. In 2015, at dotSwift, the first Swift conference in Paris, I watched Daniel Steinberg compare it to French cuisine, as opposed to fast food. The image stuck with me, I still prefer fine dining, and it has become a running joke with our junior developers.

In October 2026, an experiment on Objective-C added weight to that hunch. Fernando Olivares, an iOS developer at 37signals, asked two agents, Claude Opus 5.5 and GPT-6.1 Sol, to build the same chat screen in Swift and in Objective-C, then measured everything on an iPhone 12 and published the code and the results. The agents wrote the Objective-C, and it is the leanest version, on a single measurement pass per version: 35 MB of memory at peak, against 44.5 MB for the best Swift version built with the same framework.

I'm not betting on an Objective-C comeback for all that. But what the experiment shows is serious: an agent effortlessly writes a language we found tedious, and that applies first of all to Rust.

The price of Rust

Rust is the language developers admire most: in the 2026 Stack Overflow survey, 67% of the people who use it want to keep using it, a score no other language reaches. Yet many admire it from a distance. Its compiler rejects anything that isn't safe, and it takes a long time to stop fighting it.

Objective-C was paid for in lines to type, with brackets everywhere. Rust is paid for in compiler rejections. In both cases, the cost fell on the people writing the code. For years, we chose our languages for their comfort.

What the agent changes

An agent doesn't get tired. Writing a forty-character method name costs it a few tokens, not its patience. And the Rust compiler's rejections, which discourage a human, become a free check on its own work.

The first measurements point the same way. When SWE-bench Multilingual launched, a benchmark that asks an agent to fix real issues in nine languages, Rust was the language where the agent succeeded most often, and C or C++ where it succeeded least. In July, a team showed that feeding the Rust compiler's errors to the model while it writes brings the share of code that doesn't compile down from 20.7% to 13.1% (arXiv 2607.13921).

When writing costs almost nothing, what's left is what the language guarantees. For Rust, that's memory safety, and the stakes are concrete: at Chromium, around 70% of serious security bugs are memory safety problems.

And projects are already following. A team studied GitHub projects that use coding agents: among those created after August 2025, the share of Rust projects doubles, 10.5% against 5.3% among older ones, while C and C++ decline (Robbes et al., arXiv 2606.07448). Niko Matsakis, one of Rust's longtime designers, sees it too: in his words, Rust "happens to be a really good fit for agentic coding", and he draws ideas from it for evolving the language. I see it from another angle, that of the price of these languages, which has changed hands.

What I see at work

We needed Rust on a specific project: the same calculation had to give exactly the same result in the browser and on our servers. Writing two versions, one in JavaScript and one on the server side, meant accepting that they would eventually drift apart. Rust compiles to both, but it wasn't part of our stack. We're very happy with the result and the experience, but let's be honest: without agents, we wouldn't have tried.

The same mechanism plays out, more modestly, in our iOS engine. Born in Objective-C in 2011, it was gradually migrated to Swift, because it was getting hard to find developers who master Objective-C. The parts we no longer evolve stayed in their original language, and we can now fix them without depending on whoever on the team can still read it.

Further out: proof languages

Rust isn't the most demanding language. With Lean or Dafny, you write the program, and also the mathematical proof that it does what you expect. The human price is huge: according to Martin Kleppmann, proving the 8,700 lines of C in the seL4 kernel took 20 person-years and about 200,000 lines of proof. Few people know how to write these proofs, and almost nobody does it for ordinary code.

Kleppmann draws a prediction from it: AI will make formal verification mainstream. His argument is the Rust compiler's, pushed to the limit: the proof checker rejects any invalid proof and forces the agent to retry, so a made-up proof doesn't get through.

The numbers partly bear him out. In a study published in September 2025, the models' success rate on Dafny verification tasks had risen from 68% to 96% in a year. At the same date, they solved only 44% of the problems in Verus, the version of Rust built for proofs, and 27% in Lean. Verus is newer, and models have seen less of it.

What I take from it

The question "which language?" had stopped being asked: we took the most comfortable one, and paid the difference elsewhere, in memory vulnerabilities or in bugs no proof had ruled out. Agents reopen the question. We can once again choose a language for what it guarantees, as long as the model knows it well enough.

Cover photo by Judith Browne on Unsplash.

Mathieu Poli, Head of Frontend Engineering at GoodBarber. I write about frontend engineering, product design and AI.

X: hellomathieup · LinkedIn: hellomathieup

Adding tools to an MCP server that ChatGPT has already approved

Pierre-Laurent Medori — Tue, 20 Oct 2026 12:03:14 +0000

On October 7 we added seven tools to our public MCP server: read the booking calendars of an app, list sessions, cancel a booking, manage closing days. The server is listed in ChatGPT's directory and in Claude's, and people also connect to it directly from Claude Code, Cursor and others. The question I asked before anyone wrote code: how do we add tools for the direct users without touching what ChatGPT approved?

One line of context: I run engineering at GoodBarber, an app platform, and our MCP server lets assistants manage the apps through an authenticated connection.

One server, three audiences

The first step was a map of who sees what. I had a rough idea; the code had the exact one.

audience	what it gets	what a new tool does
ChatGPT app	a frozen list of 45 tools, the ones OpenAI reviewed	absent from the list; a call to it is refused
Claude directory	the full catalog, which follows each deploy	appears with no new submission; the tool names shown on the listing page are updated by hand
Direct clients	the full catalog	appears

So a new tool is free for the Claude directory and for direct clients, and the frozen list keeps it away from ChatGPT. That could have been the whole plan.

The coupling no test covered

The ChatGPT side is a facade over the same catalog. It picks the 45 tools and overrides their descriptions, plus one schema. Everything else it serves, the titles, the input schemas, the annotations that say whether a tool reads or writes, comes from the code shared with every other audience.

That means a change made for the new tools, say a tweak to the helper that turns tool names into titles, or to the function that builds annotations, would also change what ChatGPT serves for tools OpenAI already reviewed. Nobody would notice: the existing test only checked the names and the order of the 45.

So step zero, before any booking code, was a test that freezes everything ChatGPT sees, for several configurations the facade serves: name, title, description, input schema, annotations, compared to a committed reference file. Any difference fails CI and names the tool. Simplified:

def test_chatgpt_surface_matches_reference():
    served = {tool["name"]: tool for tool in chatgpt_tools_for(SAMPLE_APP)}
    reference = json.loads(REFERENCE.read_text())
    assert served.keys() == reference.keys()
    for name, expected in reference.items():
        assert served[name] == expected, f"{name} changed for ChatGPT"

Then we checked that the test can fail. The first attempt changed a field, and the test stayed green. Not because the test was wrong: that field is rewritten by an override before it reaches ChatGPT, so the change never got there. The second attempt added a field nothing overrides, and the test failed, naming the tool. A guard you haven't seen fail is a guess.

A second test checks the other direction: none of the new tools reaches ChatGPT.

With both in place, the booking work could touch the shared code freely. If it moved something OpenAI had approved, CI would say so before a deploy did.

A tool that cancels bookings

Four of the seven tools read. The three that write are the reason this section exists.

Creating a closing day in the back office cancels every booking on that day and sends each attendee a cancellation email. If the app's calendars inherit closing days from a default one, the closure applies to all of them. A person in the back office sees a confirmation dialog. A model sees a tool description, and a tool description is a suggestion.

So the tool checks before it acts:

it counts the bookings that the closure would cancel, across every calendar it would apply to;
if there are any, it creates nothing and returns confirmation_required with the count;
it only goes ahead when the call carries cancel_existing_bookings: true;
it refuses past days;
it is annotated as destructive, and its description says what happens to attendees.

The model can still cancel twenty bookings, and nothing stops it from setting the flag on its first call. What it can't do is cancel them by default: a call that doesn't ask for it returns the count, and the description tells the model to show that count to the user and get a yes first. That part is an instruction, not a lock.

Deleting a closing day makes the day bookable again if the calendar opens on it, but restores none of the bookings the closure cancelled. That one is not destructive in itself, and it's the kind of thing a model would assume: undoing the closure undoes the cancellations. It doesn't, and the description says so.

Cancelling a booking uses the same call as the back-office button, with the same email to the attendee. A booking that is already cancelled comes back as "not found, nothing was changed" instead of an error, so a model that retries after a timeout, or after the attendee cancelled from their own link, doesn't report a failure that didn't happen.

Access: a permission, not a list of pilot apps

Booking data includes attendees' names and emails, so the tools got their own permission in our API credentials service, read-only or read-write, offered only to the app type that has bookings. Existing keys don't get it; someone has to tick it.

That gave us a safe deploy order with no list of pilot apps: ship the server first, with tools nobody can see because no key carries the permission; then create the permission, which is the moment they become available. One decision went the other way on purpose: new keys pre-select every service in read-only, and bookings follow the same rule as the others.

The metadata that drifts

The tools were live in minutes. The descriptions of the server took longer.

The server card builds its tool list from the catalog, so it showed the new tools right after the deploy: 157, up from 150. Its version, though, was written by hand, and it was already behind the version in our registry entry. Both moved to 1.3.0.
The registry entry has a 100-character description. Adding "bookings" meant "mobile app" became "app". The publishing token had expired, so that took a new login.
The Claude directory listing shows a list of tool names that is edited by hand and validated by a reviewer, one of the details I went through in what each MCP directory actually checks. The tools themselves were already available to Claude users; the listing just didn't say so yet.
The ChatGPT app needed nothing. Nothing it serves changed, and the frozen test is what lets us say that. The day bookings should reach ChatGPT, that will be a new version of the facade and a new submission, on purpose.

Before the deploy, every call to the booking API ran against mocks, since only the production server is allowed to call it. The first real call came after the deploy, from a test key with only the booking permission. It worked.

What I'd keep

Map your audiences from the code, not from memory. ChatGPT's frozen list was the part I knew about; the shared code underneath it was the part I didn't.
Freeze what a reviewer approved, not what you meant to ship. Names and order are what you think of. Schemas, titles and annotations are what a shared helper changes behind your back.
Watch the guard fail once. Our first attempt at breaking it changed a field that never reaches ChatGPT.
For a model, a confirmation dialog is a refusal with a number in it. Return what would happen, and require an explicit flag to make it happen.
Gate new tools with a permission. It gives you a deploy where the code is live and the capability isn't.

If your MCP server is listed somewhere: what exactly did the reviewer approve, and which test would tell you it changed?

How do you manage CORS for thousands of customer domains? Per tenant, with three answers instead of two

Pierre-Laurent Medori — Thu, 15 Oct 2026 13:19:58 +0000

Our domain registry can stop answering. It can also answer that a customer's domain is no longer allowed. Both cases leave the proxy without a usable current list, but only the first gives us a reason to reuse an older one.

That distinction shaped our per-tenant CORS cache. We keep valid results for 15 minutes and a fallback copy for 24 hours. An authoritative refusal erases that fallback, so the next outage cannot bring a removed domain back.

One domain per customer

At GoodBarber, the web version of each customer app has its own domain, either a platform subdomain or a custom one. We are piloting a proxy that lets widgets call third-party APIs while their private keys stay on the server. Its CORS policy has to fit that domain model, even while the service itself is limited to a small pilot.

Our first static allowlist was manageable for five pilot apps. It could not follow the platform's thousands of domains as customers changed them. Allowing arbitrary origins would also defeat the restriction we wanted; PortSwigger documents that mistake in its guide to CORS misconfigurations. We needed to resolve the list for each tenant.

The preflight does not know who is calling

An actual API call carries a short-lived token naming the tenant. Its preflight arrives earlier, without that token: CORS preflight requests do not carry credentials. We receive an origin, a proposed method and a list of header names, so the token cannot supply the tenant for this lookup.

The request path can. It contains an opaque connector handle belonging to one tenant. We resolve the handle, then the tenant's domains. Because this happens before token validation, the lookup must also tolerate requests from arbitrary callers.

Origins, exactly as a browser sends them

The registry returns a domain. A browser sends an origin, and the comparison is string equality, so the list has to be built the way a browser would write it.

The default port for the scheme is omitted: :443 for HTTPS, :80 for HTTP. Non-default ports are kept.
A custom domain yields two origins, with and without www, since customers publish both. A subdomain of ours yields exactly one.
An internationalised domain is converted to punycode, which is what the browser sends.
The response carries the one matching origin and Vary: Origin, as MDN recommends for an explicit origin. Never *, and Origin: null never matches.

A miss needs a reason

Once the main cache entry expires, the registry lookup can produce three different outcomes:

The registry…	What the proxy serves	What it stores
answers with domains	those origins	the list for 15 minutes, and a second copy for 24 hours
cannot be reached, answers an error or sends garbage	the 24-hour copy, if there is one	the main entry again, for 60 seconds
answers clearly that the tenant has no usable domain	no CORS headers	an empty list for 60 seconds, and it deletes the 24-hour copy

The outage path borrows the idea of stale-if-error. Apps can keep using a previously accepted origin while the registry is unavailable. Caching that fallback decision for 60 seconds reduces repeated lookups; it does not by itself guarantee a global request-rate bound when concurrent misses occur.

An explicit removal has a different meaning. If we kept its old list, a later registry outage could restore the revoked origin from the 24-hour copy. Deleting that copy makes the refusal survive the outage too.

The pre-auth path is bounded

Before any I/O, we check the handle's shape and hash it for use in cache keys. Unknown handles are cached as unknown for 60 seconds. If the shared cache is unavailable, an in-process cache lasting 5 seconds, with at most 4,096 entries, limits repeated database work.

The preflight path responds with 204. If neither the lookup nor its permitted fallback yields an allowed origin, the response omits CORS headers. Dependency errors therefore do not become a 500, and the browser cannot proceed with the cross-origin call after an unsuccessful preflight.

Treat your cache as input

The cache is shared infrastructure, so what comes out of it is validated like anything else that crosses a boundary. Values are JSON, never pickled objects. Every list read back is checked, item by item, against the same pattern that judged it on the way in. A value that exists but fails that check is ignored and logged as a tampering signal.

Review found a mismatch here. Normalisation accepted a hostname containing an underscore, but cache validation used a stricter rule and rejected it. That value would have been repeatedly written, discarded and fetched again, leaving both caches ineffective for the tenant. Applying the same rule on write and read removed the disagreement.

CORS is not the lock

These responses govern browser access. A client such as curl does not enforce them, so actual requests still undergo token validation and the connector's permission checks. Using an older CORS list leaves those checks in place; it changes which browser origins may read the responses.

The feature and its hardening landed on July 23, six minutes apart: the second commit is the adversarial review of the first. The module has 48 tests: normalisation, the three outcomes, the bounds of the pre-auth path, and the few static origins we add on top.

To test the distinction, cache an allowed domain, have the registry explicitly remove it, then make the registry unavailable. The domain should remain absent. Testing an outage alone would miss the case where a cache reverses a decision it had already received.

Fail-closed or fail-open? Decide per side effect, then check what your cache already decided

Pierre-Laurent Medori — Tue, 13 Oct 2026 12:08:46 +0000

Fail-closed: when something a decision depends on is unavailable, the answer is no.

Fail-open: the answer is yes.

Fail-bounded: the answer is yes, inside a limit that does not need the missing dependency.

"Fail-closed or fail-open" is the wrong question at the scale of a service. Ask it per dependency and per kind of request. And before you answer, check your cache client: ours was configured to swallow errors, which turns every security decision built on it into fail-open without anyone deciding so.

Why two words are not enough

The third definition has no standard name, and it is the one we use most. OWASP's principle is called fail securely, and it is usually read as "always closed". For a service that sits between customer apps and third-party APIs, always closed means that a cache outage takes every app's weather widget down with it. Always open means that the same outage removes the only brake on a connector that can charge a card.

Both camps are right about their half of the traffic. So the unit of decision cannot be the service.

The table

The proxy behind this table is one we are trialling at GoodBarber. It keeps third-party API keys on the server for widgets that run inside customer apps, and today it serves a few test tenants. Its security specification settles the question in one decision, written before the code: the degraded mode depends on the side effect. A connector is registered either as read-only or as side-effecting, next to its host and its allowed methods, and every dependency gets a row. Everything below is conditional on that flag being right. The proxy applies the column it is given. It does not infer the class from the traffic, so a connector wrongly registered as read-only gets the lenient column.

When this is unavailable	Read-only connector	Side-effecting connector
The keys that verify token signatures	refused, `503`	refused, `503`
The rate limiter's shared store	allowed, inside a per-process ceiling	refused, `503`
The kill switch	cannot be unavailable on its own: it lives in the primary database and is read on every request	same

The first row has no nuance. A signature you cannot check is not a valid signature, whatever the request does. The status code matters as much as the refusal: 503, never 401. A 401 tells the client its token is bad, and a well-behaved client responds by asking for a new one, which turns an outage of the key endpoint into a stampede on the token endpoint.

The third row is a placement decision. A kill switch that lives in a cache disappears exactly when the infrastructure is having a bad day, which is when you reach for it. Ours is a column in the database the request already needs.

The option in the middle

The second row did not start that way. In the first version, read-only traffic simply passed when the limiter's store was down. An adversarial review, run before the first commit of that code landed, flagged it, and the reason fits in one sentence. "Read-only" describes the effect on the third party, not the cost to us or to the customer's API quota. Fail-open on reads is still an unmetered pipe.

The fix is a few lines, and it is the whole idea of fail-bounded:

try:
    ok = hit(tenant) and hit(tenant, connector) and hit(tenant, host)   # shared store
except StoreUnavailable:
    if side_effecting:
        return FAIL_CLOSED                       # 503: no brake, no payment
    return ALLOW if local_window_allows(tenant, connector) else THROTTLED
return ALLOW if ok else THROTTLED

local_window_allows is a sliding one-second window kept in the worker's memory. It is cruder than the shared limiter and it needs nothing that can be down. It is also per process, so the real ceiling is that number multiplied by the number of workers. Reads keep flowing, and "how much" still has an answer.

The setting that had already decided

This is what I would check first in any codebase. Our Redis cache is configured with django-redis's IGNORE_EXCEPTIONS, which its documentation describes as memcached-like behaviour: when the server is unreachable, a read returns None and a write does nothing. For a cache, that is the right call. A cache that is down should look like a cache that is empty.

A rate limiter built on that client inherits the setting. incr does not raise. It returns None. A naive comparison then either crashes or, written a little differently, treats "no answer" as "under the limit". Nobody chose fail-open. A convenience flag, set once for caching, chose it for every security decision stacked on the same client.

A shared client's error policy is a security decision for everything built on top of it. So the limiter treats silence as a failure, explicitly:

current = cache.incr(key)
if current is None:              # the client swallowed a backend error
    raise StoreUnavailable       # silence is a failure, not "under the limit"

One of the six tests of that module exists only for this case, and its name says so: none_from_ignore_exceptions_is_treated_as_unavailable.

Here is the whole chain during an outage. Redis stops answering. incr raises nothing and returns None. The limiter calls that unavailable, and the table decides: 503 for a connector that can charge a card, a local ceiling for one that reads the weather.

How do you prevent SSRF in a proxy that calls third-party APIs? Never accept a URL

Pierre-Laurent Medori — Thu, 08 Oct 2026 12:03:13 +0000

The contract for our API proxy has no target-URL parameter. A widget sends a connector handle and a relative path. The server loads the destination registered for that connector, then checks whether it is still safe to call.

That choice rules out the usual request saying, in effect, "fetch this internal address for me". It leaves several ways for a registered destination to become unsafe, including DNS changes and redirects. Those are the cases the rest of this article covers.

Who gets to choose the destination?

We built this proxy for GoodBarber, where generated widgets need to call third-party APIs without receiving the private keys themselves. The AI extension feature is still a prototype in a small pilot. The proxy holds the credentials and injects them into outbound requests, which makes its destination checks part of the secret's protection.

The OWASP cheat sheet on SSRF distinguishes services that can restrict calls to known destinations from those that must fetch arbitrary URLs. We chose the first model so that an authenticated owner could approve a destination before a widget used it.

The decision: a handle, not a URL

The handle is a random identifier. It selects a server-side record containing the scheme, host, base path and permitted methods. The caller supplies the relative path, query and body:

What the widget sends            What the server already holds
-----------------------------    ---------------------------------------
handle:  k3J…x9  (opaque)        base URL:  https://api.example.com/v2
path:    /forecast?city=Paris    allowed hosts, allowed methods
body:    { … }                   the secret, encrypted

When the owner approves an API and supplies its key, the base URL goes through the same validation function used for subsequent requests. Approval records the intended destination; it cannot guarantee what that hostname will resolve to later.

What is left to defend

Each outbound request still has to satisfy these checks:

Vector	What we do
The host is an IP in disguise: `2130706433`, `0x7f000001`, `127.1`, octal forms	rejected before any resolution: a destination must be a real hostname, and a name whose labels are all numeric or hexadecimal is refused
The name resolves to an internal address	blocked on the resolved IP, not on the string: loopback, private ranges, link-local and its cloud metadata address, carrier-grade NAT, and their IPv6 equivalents
One public A record and one private one	every address in the answer is validated, and a single forbidden address rejects the whole answer
DNS rebinding between the check and the connection	one resolution, then the connection goes to the validated IP
An IPv4 address wrapped in IPv6	IPv4-mapped and NAT64 addresses are unwrapped and the embedded IPv4 is validated too
A redirect to somewhere else	redirects are never followed, the 30x status goes back to the caller as it is
`../` to escape the registered base path	the path is normalised first, then compared with the base path
Headers that change the meaning of the request	three headers are relayed from the client: `Content-Type`, `Accept`, `Accept-Language`. `Host`, forwarding headers and method overrides are set or dropped by the server
A proxy configured in the host's environment	the HTTP client ignores environment proxies
Lookalike hosts such as `api.example.com.evil.com`	host matching is exact equality, never a suffix or a pattern

The NAT64 case came from an adversarial review before the first commit. In the well-known prefix defined by RFC 6052, 64:ff9b::7f00:1 embeds 127.0.0.1. An IPv6 classification alone can miss the address a translating network would reach. The embedded IPv4 address needs validation too.

Cloud metadata is one reason that distinction matters. AWS added IMDSv2 in 2019 as defense in depth against SSRF and related paths to instance metadata. Our proxy rejects those destinations rather than relying on the target to resist the request.

Connect to the address you validated

Checking a name and then handing the same name to the HTTP client is two resolutions, and the second one can answer differently. The fix is to resolve once and pin.

def resolve_and_pin(host: str, port: int) -> str:
    ips = resolve_ips(host, port)               # one resolution, A and AAAA
    for ip in map(ipaddress.ip_address, ips):
        if is_blocked_ip(ip):                   # one bad address rejects the whole answer
            raise SsrfBlocked(host)
    return ips[0]                               # the address we will connect to

The request then goes to that IP, while TLS still verifies the real hostname:

url = httpx.URL(scheme="https", host=pinned_ip, path=path)
headers["Host"] = hostname                                              # the real name, set by the server
request = client.build_request(method, url, headers=headers, content=body)
request.extensions = {**request.extensions, "sni_hostname": hostname}   # SNI and certificate check too

The Host header and the SNI carry the real name, so certificate verification is as strict as on a normal call, and it is never disabled. The socket layer has nothing left to resolve. The client is created with follow_redirects=False and trust_env=False.

The read timeout that never fires

An upstream can keep a worker occupied by sending one byte every twenty seconds. That never trips a 25-second httpx read timeout, because the timeout limits the wait for each chunk. We therefore put a wall-clock deadline around the exchange, including body streaming:

async def forward(...):
    # httpx's read timeout restarts at every chunk. This deadline does not.
    return await asyncio.wait_for(_execute(...), timeout=TOTAL_DEADLINE)   # 30 s, for a 25 s read timeout

The response size is capped the same way, by counting the bytes actually streamed, not by trusting a Content-Length header.

The key arrives last

Decryption happens after the destination checks. A request rejected for its method, path, host or resolved address therefore does not load the plaintext credential. Once admitted, the request receives the key for the approved upstream.

What the decision costs

Adding another API requires another approved connector. A widget cannot discover an arbitrary endpoint and ask our server to call it. That restriction suits a platform where an app owner approves which services receive their credentials.

The egress code landed on July 7 with 105 tests, including 18 for SSRF cases such as numeric hosts, mixed DNS answers, NAT64 and rebinding. Its specification contains 19 egress requirements. The tests cover the checks; the request contract limits what those checks have to accept.

In a review of another proxy, I would start where the outbound URL is constructed. Trace each component back to its source, then follow the chosen host through resolution and connection. A validator can be correct while the HTTP client quietly makes a different request.

How do you give local content in a WKWebView a real https origin? (iOS 17)

Pierre-Laurent Medori — Thu, 01 Oct 2026 11:45:29 +0000

On September 16 I opened a test widget on my iPhone. At the top, a quote that loads when the widget opens. Under it, two text areas and a Compare button that returns a similarity score. Two calls to the same third-party API with the same key: a GET for the quote, a POST for the score.

The quote appeared. The Compare button answered with the only sentence its code can say when that call fails: "Impossible de calculer la similarité. Veuillez vérifier votre connexion." Unable to compute the similarity, please check your connection. The connection was fine, my Android test phone did exactly the same, and in a browser both calls worked.

GET works, POST fails. I spent a morning on the verb. The cause was the page's origin, and the GET had never worked.

This piece is about that origin: where a page in a WKWebView gets one when its files live on the device, how our iOS engine now serves them from a fixed https://secure.internal with a proxy API that arrived in iOS 17, and what changing an origin breaks in places no crash log reaches. The widget comes back at the end, once the dates make sense.

Why local content needs an origin at all

At GoodBarber, an app builder for native iOS and Android apps, some sections of an app are web content: custom code written by the app's owner, HTML widgets, extensions. The files live on the device so that the section opens offline. On iOS they are displayed in a WKWebView.

How those files are served decides whether the page is a secure context, a prerequisite for APIs such as crypto.subtle. It also sets the origin seen by CORS and CSP checks, cookie behaviour, and where localStorage and IndexedDB data are stored.

One of those checks is ours. My team is piloting an extension builder, where I look after the backend: the owner of an app asks for a feature in a sentence, a model writes it, and the result runs in the app's web version and inside its native apps. A widget that needs a private API key never holds it. The page frames a small page served by our token issuer, gets a short-lived token, and calls a proxy of ours that keeps the key. The issuer lets only approved origins frame its page, through a CSP frame-ancestors directive. So the origin a native shell gives its local files decides whether any of those widgets can work at all. The builder has not shipped to customers, and the phones in this story are my own test devices.

Change the serving mechanism and all of that changes with it. We went through three versions in one year.

Three origins in one year

Period	How the page was served	Origin	What it cost
before June 2026	an HTML string with a custom base URL, files through a `WKURLSchemeHandler`	a custom scheme	not a secure context, an `Origin` header that third-party servers do not recognise, `Secure` cookies ignored, URL rewriting and a permissive CSP to hold it together
June to August 2026	a small HTTP server inside the app, bound to loopback	`http://127.0.0.1:<port>`	a secure context and plain HTTP semantics, but an IP address and a changing port in the origin
since September 2, 2026	a loopback CONNECT proxy in front of a TLS listener	`https://secure.internal`	iOS 17 minimum for this approach, and web storage starting from empty once

The second step was already a big one, and our iOS team built it as a real server: request parser, range requests for media, keep-alive, recovery when the listener dies. It also relays the page's cross-origin fetch calls, which the shell rewrites towards it. Loopback is a potentially trustworthy origin, so the page became a secure context and third-party scripts finally saw an http origin they understood.

The remaining problem was the port, assigned at runtime. There was no single origin to put in a remote allowlist. On July 30 the token issuer started accepting http://127.0.0.1:*, which is valid CSP and accepts any port, including any unrelated local server on the phone. A fixed https name would give the app and those services a value they could agree on.

WebKit will not hand over https

Apple's documentation for setURLSchemeHandler(_:forURLScheme:) rules out the direct approach: registering a handler for a scheme WebKit already handles, such as https, raises an exception.

Android takes the opposite position. shouldInterceptRequest lets an app answer any request, https included, and WebViewAssetLoader packages the pattern with a domain reserved for it, appassets.androidplatform.net. Our Android engine moved from file:// to that loader on July 31, a fixed https origin came with it, and the issuer accepted it the same day.

That Android approach does not transfer to WKURLSchemeHandler.

Why not a real certificate for a real domain?

The tempting shortcut is a public hostname that resolves to 127.0.0.1, a certificate from a public authority, and the private key shipped in the app. Let's Encrypt has a page about certificates for localhost whose answer is: don't. A private key distributed in an app is a compromised key, the certificate may be revoked, and the DNS lookup gives an attacker something to intercept. It also makes an offline section depend on DNS.

We could still use a certificate whose trust was limited to our own WebView. It did not need recognition from a public authority.

The piece that arrived with iOS 17

iOS 17 added proxyConfigurations to WKWebsiteDataStore, fed by the Network framework's ProxyConfiguration. Apple presented it at WWDC23 for network relays, with a remote relay in the example. Nothing says the proxy has to be remote.

import Network
import WebKit

// The CONNECT proxy is a listener our own app opened on loopback.
let proxy = NWEndpoint.hostPort(host: "127.0.0.1",
                                port: NWEndpoint.Port(rawValue: connectProxyPort)!)

var configuration = ProxyConfiguration(httpCONNECTProxy: proxy, tlsOptions: nil)
configuration.matchDomains = ["secure.internal"]  // only this name uses the proxy
configuration.allowFailover = false               // never try a direct connection

WKWebsiteDataStore.default().proxyConfigurations = [configuration]

Those two properties carry the design. With matchDomains, WebKit sends CONNECT secure.internal:443 to our listener instead of resolving the name, so the name never reaches DNS and the section opens in airplane mode. With allowFailover off, WebKit never falls back to a direct connection, so the name cannot leak to a resolver while our server is restarting.

Inside the app, three loopback listeners do the work:

A TLS listener serves the files. Its identity is embedded in the app: self-signed, RSA 2048, a single SAN secure.internal, TLS 1.2 minimum, ALPN http/1.1.
A CONNECT proxy on a port the OS assigns. It accepts exactly one request, CONNECT secure.internal:443, and pipes the bytes to the TLS listener. Anything else gets a 403.
A plain HTTP fallback for media, in case the media stack does not follow the data store's proxy.

The configuration is pushed again every time the server restarts, since the port changes, and before the WebViews are told to reload.

Accept one certificate, for one host

A self-signed certificate fails the system's trust evaluation. That is expected, and the navigation delegate is where it is settled. Ours is Objective-C. Here is the same logic in Swift:

func webView(_ webView: WKWebView,
             didReceive challenge: URLAuthenticationChallenge,
             completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
    let space = challenge.protectionSpace
    guard space.authenticationMethod == NSURLAuthenticationMethodServerTrust,
          space.host.caseInsensitiveCompare("secure.internal") == .orderedSame,
          let trust = space.serverTrust else {
        completionHandler(.performDefaultHandling, nil)  // every other host: the normal path
        return
    }
    let chain = SecTrustCopyCertificateChain(trust) as? [SecCertificate]
    let leaf = chain?.first.map { SecCertificateCopyData($0) as Data }

    if leaf == pinnedCertificateDER {                     // byte-identical to the embedded one
        completionHandler(.useCredential, URLCredential(trust: trust))
    } else {
        completionHandler(.cancelAuthenticationChallenge, nil)
    }
}

The exception applies only to that host and that exact certificate. Every other host follows normal trust evaluation.

The embedded key is shared across our apps and can be extracted from a binary. We treat it accordingly. The design rests on the local routing and on the delegate's narrow trust decision; it does not give the certificate public authority or make it an app identity.

One more gate sits in front of the files. Loopback listeners are reachable by other processes on the device, so every URL starts with a random token generated for the session, and a request without it gets a 403.

Choosing the name

Since the name never touches DNS, it is cosmetic. It shows up in location.origin, in the web inspector and in server-side allowlists, never in front of a user. Two constraints still apply: the suffix must never be delegated on the public DNS, and no certificate authority must ever issue for it.

That rules out .app, which is a real top-level domain, and .local, which belongs to multicast DNS and answers on the local network. It points at .internal, which the ICANN Board reserved for private-use applications on July 29, 2024, permanently excluding it from delegation in the DNS root zone.

What we measured

The new engine landed on September 2, and the issuer swapped http://127.0.0.1:* for https://secure.internal the same day. These are the September 4 verification runs: iPhone 15 Pro simulator, iOS 17.4, our internal app in Debug, two real customer apps loaded in it.

Check	Result
Page loads logging `location.origin` and `isSecureContext`	43 loads across plugin sections, HTML widgets and scratch sections, 43 times `https://secure.internal` and `true`
`crypto.subtle`	present
TLS handshake through the tunnel	TLS 1.3, 6 ms
Import of the embedded identity	3.7 to 4.0 ms, measured four times
Live CONNECT tunnels	peak of 1, back to 0 after each cycle
Native bridge, storage round trip, cross-origin GET and POST relays	exercised on 9 scopes towards 3 remote hosts
Backgrounding for 50 seconds, then return	the WebView survives and the appear event fires again
Video rendering	not testable on the simulator, whose WebKit GPU process is denied GPU access; normal on a device

What the https origin changed

Mixed content appeared. Old custom code links http://fonts.googleapis.com/… stylesheets, in dozens of HTML files across 12 sections of a single test app. Under an http origin nobody noticed. Under https, WebKit blocks them as active mixed content and the page silently loses its fonts. The server now adds Content-Security-Policy: upgrade-insecure-requests to HTML documents, and to nothing else. Our Android engine met the same files after its own migration.

Tunnels have to die on the first EOF. A 28-minute capture showed 68 CONNECT tunnels alive at the same instant, all killed together with ENETDOWN when the app was suspended. Our relay waited for both directions to finish before closing, and WebKit keeps its side open and idle. A CONNECT tunnel is done as soon as either peer stops writing. With that rule, and a counter logged on every open and close, the peak is 1. ENETDOWN on suspension is now logged as a routine end of life, because it is one.

Web storage starts from empty. localStorage, IndexedDB and cookies are filed by origin, and WebKit offers no supported way to move them from one origin to another: WKWebsiteDataStore can enumerate and delete by origin, not read or rewrite. A custom section that kept a login token asks for the login once after the update. That is the visible price of an origin change.

The fourth change has no log line at all. It is the widget from the first paragraph.

Back to September 16

The phones ran internal builds of our shells from early summer. That morning I built both engines on my laptop and ran the same widget on fresh installs.

Surface	Native shell	GET, the quote	POST, the score
Web	none, a browser	ok	ok
iOS simulator	built that morning	ok	ok
Android emulator	built that morning	ok	ok, 48%, no console error
Test iPhone	internal build, early summer	a quote was displayed	error message
Test Android phone	internal build, early summer	a quote was displayed	error message

Same bundle, same backend, same key. The only variable left was the shell installed on the phones. Read the last two rows again: I wrote "a quote was displayed", not "ok". That morning I wrote "ok".

The verb was a good suspect, because a WebView does treat a request with a body differently. Browsers attach an Origin header to a same-origin POST and not to a same-origin GET, as the Fetch standard specifies, so any guard that compares Origin to an expected value is only ever exercised by POSTs. On Android, shouldInterceptRequest hands the app a WebResourceRequest with a URL, a method and headers, and no body. On iOS, our relay has to buffer the whole body before forwarding anything, and a GET has nothing to buffer. One fact should have cooled me down: both calls carried a bearer token in an Authorization header, which makes both of them preflighted cross-origin requests. For CORS, my GET and my POST were in the same class.

The coding agent I was pairing with asked for one trace from the phone, Safari's Web Inspector or chrome://inspect. I chose to build instead, because a build feels like progress. It worked, and this went into my notes: an outdated app relays the GETs and loses the body of the POSTs; check the build date before you look at the server. The second half is good advice. The first half is a mechanism nobody observed. The fix was right, the cause was invented.

Two days later I asked the same agent to draft an article from that session. Before writing the mechanism down for strangers, it checked it against git history, and the dates in this article do not allow it.

The iOS relay has buffered the complete body since the day it was written, June 4. There is no older relay that drops bodies for a phone to be outdated with.
On September 2 the issuer stopped accepting http://127.0.0.1:*. My commit message gives the reason: the feature is unreleased, and an app is rebuilt when the feature is activated for it. An iPhone build older than September 2 can no longer frame the token page. No frame, no token. No token, no call, whatever the verb.
Android builds older than July 31 load the page from file://. A file:// page has an opaque origin, and an opaque origin cannot be listed in frame-ancestors. No token there either.

So on those phones the GET could not have worked. Yet both showed a quote. The simulator still had the bundle it downloaded on the 16th, with the function that loads the quote, as the model wrote it (key name and author line shortened):

gbProxyFetch(KEY, "/v1/quotes")
  .then(function (res) {
    if (!res.ok) { throw new Error("Erreur API"); }
    return res.json();
  })
  .then(function (quotes) { /* render quotes[0] */ })
  .catch(function (err) {
    document.getElementById("quote-text").textContent =
      "« La simplicité est la sophistication suprême. »";
    /* ...and "Léonard de Vinci" in quote-author */
  })

On a shell that cannot frame the token page, the token request fails, the promise rejects, and this catch prints Leonardo da Vinci. That is what both phones were showing: Leonardo, in French. The POST went through the same failure with nothing to fall back on, so it told me to check my connection.

The asymmetry was not between two HTTP verbs. It was between two catch blocks. Nothing had worked on the phones; one of the two failures was dressed as a success. The evidence was on the screen: the API returns its quotes in English, the fallback is in French. And the SDK rejects with a typed error whose kind names the stage that failed, init when no token could be obtained. Both catch blocks received it. Neither read it.

An origin is versioned by the binary

A feature that lives in a web page inherits the page's origin, and inside a native app the shell chooses it: file://, a loopback port, a custom scheme, a fixed https name. CORS, CSP frame-ancestors, cookies and every server-side allowlist key on it. So every allowlist that names an origin is, in practice, a list of builds, and the builds are installed on people's phones on dates you do not control.

The switch of September 2 was a deliberate decision, and it holds: a rebuilt app carries the current shell, the current shell serves the origin the issuer expects, and the two move together. An app owner never meets the old origin. That works because the platform owns both ends, the native shell and the services behind it, which is also why every date in this article is known to the day. The one way to meet the old origin was to test an unreleased feature on an internal build from early summer, on the phone of the person who made the switch.

On the company blog I wrote about what quietly breaks when an app is not updated: store visibility, push delivery, OS changes. This is the same decay seen from the server side. An allowlist moves, and every build older than that date loses a capability, without a crash and without a line in the phone's log.

What I check first now

Is the half that works real? Before comparing a GET and a POST, find out whether the GET's data came from the network. Search the page for catch. If a model wrote the code, expect a fallback: models are polite about failure, they fill the hole.
One trace from the failing device. Web Inspector or chrome://inspect, five minutes. It would have shown no request to the proxy at all, neither GET nor POST, and a refused frame in the console.
The build date of the shell, before any server log, whenever the report says "fine on the web, broken in the app". Then compare it with the dates your allowlists changed.
Substitution, last. The same bundle on a fresh shell proves where the fault is not, and says nothing about what happened on the old one. "Works on the simulator I built this morning" and "works on the phone in my pocket" are different claims. That gap is where a correct fix picked up an invented cause.

The model's fallback stays. A quote widget that shows a default quote instead of a broken box is the right behaviour for the person using the app; it is only a trap for the person debugging it. So its firing becomes visible:

.catch(function (err) {
  console.warn("[quote] proxy call failed:", err.kind, err.message);   // the line that was missing
  showFallbackQuote();
})

With that line, the first look at the console says init, no token, before anyone opens Xcode. Degrade gracefully for the user, loudly for the developer.

After the migration

https://secure.internal is shared across our apps, just as appassets.androidplatform.net is shared by Android apps using that loader. It gives browser policies a stable value to compare. Authentication still needs its own mechanism, which is what the token is for.

The practical gain is that local content gets ordinary HTTPS behaviour while staying available offline. The cost sits in everything attached to the previous origin: storage, remote allowlists, and the builds already installed. That is why the new name is boring, fixed, and meant to stay. Changing it later is another migration, even if every HTML file stays the same, and the phones in people's pockets will not follow.

The assistant is making the native app mandatory again

Mathieu Poli — Thu, 01 Oct 2026 07:25:35 +0000

For ten years, a well-built website was an acceptable answer to the question "do I need an app?". This year, Apple and Google settled how the phone's assistant will act for us, and that answer no longer quite holds. The app is becoming an entry ticket again, and not for the reasons of 2008.

My colleague Dominique Siacci explained at the end of September why agents won't kill apps: on a phone, they can't act without them, because the app already carries the identity, the rights and the relationship an agent needs. I'd like to draw the consequence for the question we've been asked for fifteen years, and which is changing its answer for the third time.

Three answers to the same question

I've been building app platforms since 2011, and I've watched the answer to "do I need an app?" change twice.

The first answer was yes, no discussion. Between 2008 and 2014, being on the home screen meant existing. An icon on the phone was worth a shop window downtown. That rush is what gave birth to GoodBarber, and to dozens of tools like it.

Then the web took back control. Progressive Web Apps, Google pushing the browser as a platform, and a decade of "you don't need an app, a website is enough". The argument was solid. So solid that we added a PWA engine next to our native engines, in 2017, and we still sell it. One project description, three outputs: Swift, Kotlin, and the web. When I say the app had become optional, I say it as someone who built the option.

The third answer is taking shape this year.

What changed this year

At WWDC in June, Apple made App Intents the door through which Siri gets into third-party apps, and deprecated the old mechanism, SiriKit. iOS 27, released on September 14, launched a new Siri meant to act and search inside apps from a single sentence. It's early days. According to Apple, it's in beta and English first. It isn't available on iPhones in the European Union, and actions in third-party apps are coming "soon". Android is heading the same way with AppFunctions, shipped in Android 16 and still in beta with Gemini. Dominique covers the mechanism, so I won't go over it again.

The door itself isn't new: App Intents have existed since 2022. What changes this year is that Apple makes it the standard way in, and that the assistant will walk through it on its own, from a sentence.

For the question of this article, one thing matters: both mechanisms are native development kits, built into an app's binary, and a web page can't register with them. There is work on the web side, WebMCP, but it targets agents running in the browser, on an open page. The phone's assistant only looks at what's installed. I'm not saying anything about adoption, which nobody knows, or about when everyone will get access. I'm saying the entry ticket is defined, by both platforms, the same way.

Why this isn't 2008

It's tempting to read this as a step back.

In 2008, having an app was about capturing attention: an icon on the home screen, notifications. The app was a shop window. Tomorrow, having an app will be about being present in the assistant: when someone says "get me a seat for Saturday's concert", it's your app or someone else's that answers. The first was won with design and marketing. The second is won by describing your app, what it does as well as what it holds, precisely enough for a machine to use it.

There's a condition, and Dominique puts it himself on his list of what would prove him wrong: the assistant only calls what's installed. To be present in the assistant, you first have to be installed, and that's exactly the 2008 problem: the shop window is still the prerequisite.

This isn't the story I told in September either. There, I was talking about the cost of building: coding agents make it cheap to build the same app three times. Here, it's about distribution: who gets to be in the assistant. Two different mechanisms, pushing in the same direction.

So, do you need an app in 2026?

The question "do I need an app?" has had one answer per era. Yes, to be seen. No, a website is enough. And now: if you want to exist, one way or another, in the phone's assistant, yes.

First, to act. Booking a class, ordering, tracking a delivery, moving an appointment: these are exactly the sentences people will say to the assistant, and it can only carry them out in a native app that has declared those actions.

But also to be found. The assistant searches as much as it acts. When someone asks it to "find me a concert in Ajaccio next weekend", it will look in the content that installed apps have described to it: Apple explicitly plans for Siri to answer questions about an app's content. It's already what apps built on GoodBarber do when you ask Siri "what's new?", from iOS 17, without their owners having to touch anything. The rollout happens in stages, and my colleague João Aleixo explains how on our blog. A cultural events calendar or a local news outlet has as much to gain as a booking app.

And the assistant doesn't only live in the phone. In the car, few apps get a place on the CarPlay screen: Apple reserves it for a few categories, navigation or audio for instance, and rebuilding an interface for the dashboard rarely makes sense. But Siri is in the car, and an app that has declared its actions can answer there by voice.

The website keeps its role: it's what people find on Google, and it's what welcomes the visitor who comes once and won't install anything. We still sell PWAs, and many projects will have both: the website for Google, the app for the assistant.

It isn't urgent. If your users are in Europe, the new Siri hasn't reached them yet, and I don't know when it will. But the entry ticket is already set, and it's a native app.

The web had made the app optional. The assistant is making it mandatory for anyone who wants to be within earshot.

Mathieu Poli, Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: hellomathieup · LinkedIn: hellomathieup

Agents won't kill apps... on a phone, they can't act without them

Dominique Siacci — Tue, 29 Sep 2026 07:08:15 +0000

At WWDC this year, in the keynote, Apple confirmed something I had been holding as a logical intuition more than as an open question: when the assistant that lives in your phone wants to do something for you, it goes into the apps installed on that phone. An app declares the actions it can perform, and that is what Siri calls. On Android, Google is building the same door under the name AppFunctions, and describes it in its own documentation as the on-device equivalent of the tools an agent calls over MCP.

Two operating systems, the same year, the same decision. Meanwhile what you keep reading in 2026 is that apps are on their way out.

Where I'm standing

I am a co-founder of GoodBarber, a platform that builds and publishes mobile apps, where I run engineering and a little bit of everything. So a piece by me arguing that apps have a future deserves the suspicion you'd give a baker writing about bread. Read it that way. Further down I list what would prove me wrong, and I'll come back with numbers when we have them.

The case against apps, taken seriously

Carl Pei, the CEO of Nothing, said it plainly at SXSW this spring: apps are going to disappear. The argument is coherent. An agent doesn't need a screen to order a pizza; it needs an endpoint. If it can reach your service through an API or a website, the app in between is a detour, and a company's real product becomes the surface its agents can call.

I believe half of it. Agents do remove navigation: nobody wants to tap through four screens when a sentence does the job. A clean, documented surface matters more than it ever did. And we run one ourselves: a production MCP server that agents call all day to manage apps, without opening a single one of them.

The disagreement is about where the agent goes when the user is holding a phone.

What I think, and I'll own it

Apple clearly wants everything the assistant in your phone does, in what they now call your intelligent personal hub, to go through the apps installed on it. And I think they're right. It's the most logical channel there is.

Not because apps are nice, or because I sell them. Because on a phone, the app is the one place where three things already exist together: an identity, a set of rights, and a relationship. Everything an agent would have to rebuild from scratch on the web is already sitting there.

The door

On a phone, the assistant doesn't browse. It calls what an app has declared. The shape is familiar if you've written tools for an agent: a name, typed parameters, a description the model reads, a result it can show or speak. The difference is that the tool lives inside an installed app, with the app's data and the app's rights, and the operating system is the one dispatching the call.

If your service isn't installed, it isn't a tool. The assistant can't find it, can't ask it anything, can't act through it. That is a hard line, and both platforms drew it on purpose.

The rights

Think about what an agent needs before it can do anything useful for a person: who they are, what they've paid for, what they've allowed, how to reach them. On the web, every one of those is a login, a consent screen, a token, a form. In an installed app, all of it already exists. The session is open. The subscription is active. The notification permission was granted months ago. The agent inherits all of it the moment it goes through the app, and it can't do more than the user could, because an interface inherits the rights of whoever it acts for.

This is why I don't think the app's role shrinks as agents get better. An agent that can act on your behalf is worth exactly as much as the rights it can act with, and those rights live in apps.

The interface

Here is where I go a step further. I think the assistant is going to be the natural way to use an app, on the phone. You say what you want; the assistant asks the app; the app answers, in the assistant, with a card, a list, a confirmation. The screens stay for what a screen does better than a sentence, comparing, browsing, checking. I wrote about an agent as the first interface you don't have to learn from the operator's side; this is the same idea reaching the person who uses the app.

And I don't think it stops at Siri. An assistant that belongs to the app itself, that answers from its content and acts within its rights, is a second way in, next to the screens, not instead of them.

Two doors, one rule

From where we sit, an app now has two doors for agents, and they don't lead to the same room. Its owner's agent talks to the server that manages the app: content, products, notifications, the things an owner does. The phone's assistant talks to the installed app itself: the things a user does. Two doors, two sides of the product, and one rule that holds on both: each door inherits the rights of whoever it acts for, the owner on one side, the user on the other.

Our engine already answers one question from Siri, "what's new", and it is reaching apps in stages. The real work is ahead, and it has a shape of its own: we don't write one app, we publish thousands from the same engine, each described by its own configuration. So what an assistant can do in an app is something we define the way we define a feature: once, in the engine, as an opening, and every app that has the feature gets it.

What would prove me wrong

I want this list to be checkable, so here it is.

The assistants route around the apps. If in two years Siri and Gemini reach most services through the web or through APIs without an installed app, and the platforms let them, the door I'm describing was a phase.
Nobody installs. If assistants don't bring people to install anything, and the only apps worth calling are the ten everyone already has, this thesis holds for the giants and for nobody else.
The door stays half-open. If third-party actions stay a demo feature, reserved for a few partners, the mechanism exists and doesn't matter.

If you ship an app: what did you expose to Siri or Gemini first for this release, and what did you decide to keep behind a screen?

Our tools are built for humans, not for agents

Mathieu Poli — Wed, 23 Sep 2026 07:20:37 +0000

You don’t need to believe AI thinks to anthropomorphize it. Handing it our tools is enough. GitHub, the pull request, code review, Scrum, the sprint, the standup, everything that organizes the work of a development team was designed to coordinate humans, and since agents started writing code, we’ve been handing all of it to them as is.

The frontend team I work in, at GoodBarber, started out adapting that way, then realized fairly quickly it was a mistake and changed course. What I take from it, personally, is that the tooling has to be redefined for machines, not adapted from ours.

Our tools are tools for humans

The standup exists so that people working side by side don’t each drift off in their own direction. The sprint bounds time because we always overestimate what we’ll ship in two weeks. The pull request keeps a record of a choice its author will have forgotten in a month, and code review puts a second pair of eyes where the first no longer sees anything.

None of these tools is about code. They compensate for the flaws of people, and they were tuned, over twenty-five years, to the speed at which people work. A Medium post titled “Built for Humans”, published in June 2026, says it in one sentence: these processes were calibrated on us.

Anthropomorphism, at industry scale

When AI coding agents arrived, we built nothing for them. An agent opens a branch, pushes commits, writes its pull request, answers the reviewer’s comments, and nobody found that strange.

A study from NAIST, published on February 19, 2026, on 33,596 pull requests opened by five agents, shows how far it has gone: depending on how the agent writes its description, humans answer it faster or slower and accept its code more or less often. We are grading a machine’s manners on a form written for colleagues.

In the other direction, a session at Stanford on April 30, 2026 proposed managing agents with Scrum and Kanban, standups included, to give them the memory and coordination they lack.

In July 2026, Kyle Galbraith of Depot wrote that GitHub is the wrong shape for this new world. His subject was infrastructure. I replied that the problem looked wider to me: Scrum, PRs, sprints all coordinate humans, and we keep anthropomorphizing AI by handing it our rituals.

Anthropomorphizing, here, means giving the machine a process designed for someone who forgets and gets tired, without having checked what that process was protecting us from.

Do pull requests work for AI agents?

Yes, they work, and that’s the trap. An agent knows how to open a PR, describe it and answer a comment. The ritual accepts it without blinking, so we keep the ritual and try to adapt inside it.

That’s what we did at GoodBarber. Before agents, the pull request was already our bottleneck. Code waited for a reviewer longer than it had taken to write. With agents, the number of pull requests exploded, our reading capacity stayed the same, and review delays started being counted in weeks. We spent our days reading code written by a machine, never catching up with the queue.

The Faros AI report of April 2026, on 22,000 developers, counts 67.4% more pull requests to handle per developer per day, so there is nothing local about it.

Reading all that code, I understood that review rested on an assumption we had never had to state: the author will be there tomorrow. They will remember why they made that choice, and they will own the bug if there is one. The whole conversation around a PR rests on that. An agent closes its session and its context is gone.

A January 2026 study of 33,707 agent-authored pull requests, picked up by Addy Osmani, sees it in the data: agents merge small, well-scoped changes fast, and disappear the moment they get subjective feedback.
The pull request assumes an author who will come back. The agent doesn’t come back.

We didn’t manage to adapt review. We removed it. In the spring of 2026 it stopped being mandatory on more and more pull requests, starting with the changes we knew how to undo, the line I described in my piece on the net. As of September 2026, it only remains on changes rated critical, the ones whose release is risky. Everything else goes through a pull request loop between agents, and ships without a human having read the diff.

The first weeks were stressful, I won’t pretend otherwise. But the productivity gain is such that we can afford to handle the misses, provided we assessed beforehand that the risk stayed contained.

Scrum went the same way, only more abruptly. A two-week sprint is tuned to one person’s throughput, and once execution moves to agents, the sprint is empty long before it ends. The “Built for Humans” post tells it as a scene: two weeks of work finished by Tuesday. What limits the team now is what it can specify and verify, and Scrum has no tool to measure that.

At the September 2026 rentrée, we used the calendar to drop our human-designed methods all at once. We’re trying other ways of working right now, and I don’t have a method to recommend yet.

What a tool for machines needs

What’s missing is the tooling that comes next. Bryan Finster published in July 2026 the experiment that gave me my diagnostic. He had agents run the same tasks with and without our disciplines: TDD, pair programming, separating author and reviewer. His result: refactoring improves the code, writing the test first changes nothing. “Refactoring is the mechanism. Test-first ordering is the ceremony.”

The mechanism serves the machine. The ceremony served the human who had to force himself to think before writing. The ceremony is the human part of the tool, and it’s exactly what we hand the agent when we anthropomorphize.

From there, we can say what a tool designed for a machine looks like, because we already know its properties in the negative.

It asks nobody to be present while the machine works, whereas a ritual rests entirely on presence.

It draws the line between what the agent executes and what it proposes on the reversibility of the mistake, not on how confident the model sounds.

It gives the agent a written context it reads before starting, in place of a meeting where someone recites it.
And it verifies at the machine’s production speed, not at a human’s reading speed.

We had to design such a tool, on a small scale, because we had no choice. When AI writes code for someone who isn’t a developer, inside our product, that person has no pull request, no sprint, no reviewer. There was no ritual to lend it.

What we wrote looks like none of our meetings: a line drawn on reversibility, and an access surface declared up front and checked server-side, a choice my CTO Dominique has written about. It’s not much, but it’s designed for the machine, and it was easier to find there than in my own team, where we had a ritual within reach.

The tooling has to be rebuilt

My position is that the next generation of development tools has to be defined for machines, not adapted from ours. A faster pull request or an automated standup keep the human shape, and the human shape is the problem.

We’ll need tools that carry context so nobody has to remember it, that bound damage rather than time, and that verify at the pace the machine produces. I don’t know yet what they will look like. I’m wary of those who already do, they usually sell one.

It’s the same conclusion I reached about frameworks: when producing gets cheap, what holds value is what remains underneath, and for a team that’s the tooling.

If you’re adapting your team to AI, look at what you’re handing it. If it’s a pull request, a sprint and a standup, you’re not adapting to AI. You’re teaching it to pretend to be one of your colleagues.

Our tools compensate for our flaws. Before handing one to a machine, ask whether it has the flaw.

Mathieu Poli — Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: @hellomathieup · LinkedIn: hellomathieup

Cover photo by nikohoshi on Unsplash.

Listing a remote MCP server in every directory: what each one actually checks (September 2026)

Pierre-Laurent Medori — Thu, 17 Sep 2026 11:52:00 +0000

The Save button did nothing. We opened the network panel. The request had returned HTTP 200.

Inside the response: a validation error on a field the form did not show.

By then we had spent several days trying to get the same remote MCP server listed across directories. Another directory had published us in about ten minutes. A GitHub list had tested our endpoint and accepted its 401. Elsewhere, our submission was waiting for a human.

"Get the server listed" had turned into a collection of different jobs.

One line of context so you know where I stand: I run engineering at GoodBarber, an app platform, and our MCP server lets assistants manage the apps through an authenticated connection. It is hosted, it requires OAuth, and there is no public server code for a directory to scan: our public repository holds skills and client configuration. That distinction decided which submission paths worked.

After getting the server into ChatGPT's plugin directory, we widened the search. What follows happened between September 7 and 14, and every public state was checked again on September 14. The delays are the ones our submissions went through, not a promise from anyone.

The official MCP Registry: publish the identity first

The official MCP Registry accepts metadata for hosted servers, closed-source implementations included, as long as the server is publicly reachable. It authenticates the publisher's namespace and validates the metadata. Beyond that, its metadata is deliberately unopinionated, and curation is left to the aggregators downstream.

Our entry, dev.goodbarber/goodbarber-public-mcp, has been there since April 28 (version 1.0.0). On September 7 we published version 1.2.1, with DNS authentication: it declares streamable-http, the remote endpoint and the product page. On September 14 the registry API still marked it active and latest.

We would do this first again. It gives importers a stable identity and a record to consume, instead of asking each directory to rebuild the product from a README.

Glama had already imported a connector entry from that record. We claimed it, and on September 8 it displayed "Ownership verified" and "Healthy". Both were still there on September 14.

Upstream publication does not tell you when the downstream pages will exist. MCP.Directory says it auto-discovers servers from the official registry, where our entry has been since April. Its submission form promises a review within 24 hours, and its first, required field is a GitHub repository, from which it detects the tools by analyzing the server's implementation. The Knights Who Say Ni wanted a shrubbery; a hosted server with no public code has no repository to give. On September 14, MCP.Directory's sitemap still had no GoodBarber URL, six days after a server listing request and five skill submissions. Where those submissions sit, we do not know.

awesome-remote-mcp-servers: the CI that accepts a 401

awesome-remote-mcp-servers is built for our shape of product. It only lists servers the provider hosts: reachable at a public URL, usable by anyone who can sign up, speaking Streamable HTTP or SSE. Each entry's name links to the product's homepage, not to a GitHub repository, because the endpoint is the thing being listed. The list was created on September 8, and our PR went in the same morning.

It also gave us something we could test. Its submission workflow at the merge commit probes each endpoint with a real initialize handshake and sends no credentials. We replayed the check before submitting. Our endpoint answered with an authentication challenge, structurally like this (generic domain):

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The workflow takes a 401 or a 403 as a live endpoint that requires authentication, and reads the WWW-Authenticate header to choose between the OAuth and API-key markers. Our 401 passed with the OAuth marker. The probe never completes OAuth and never calls a tool: a green check here means the door exists.

Two more rules matter before you open the PR. Every entry needs a Glama connector badge, and CI checks that the connector exists. And the contribution rules document a fast track for automated agents: three robot emoji at the end of the PR title. Our PR was prepared by an agent, so we used it. PR #4 was opened at 07:23 UTC, labeled endpoint-ok and has-connector by CI nine seconds later, and merged at 13:50 UTC, on September 8.

Then the bot ran again on the merged PR. It added duplicate and missing-connector, removed has-connector, and asked us to remove the duplicate entry. The duplicate was ours: the check was now reading the list it had just merged. The README on the main branch settled what the labels could not.

Gemini CLI and GitHub: a crawler versus a review queue

The Gemini CLI gallery instructions describe a daily crawl of public GitHub repositories carrying the gemini-cli-extension topic. A gemini-extension.json manifest at the root of the repository supplies the metadata, and an extension appears in the gallery only if it passes validation. The instructions say there is no issue to file and no email to send.

We added the topic on September 9. On September 14 the topic and the manifest were in place, and the gallery page had no GoodBarber entry. A daily crawl gives no per-repository result, so we cannot tell whether we failed validation or were never picked up.

GitHub's MCP gallery has another gate. In discussion #1257, a GitHub answer explains that onboarding a new server is a manual curation process, and that new registry versions sync once a server has been onboarded. We asked to be included on September 8; on September 14 the expected gallery URL still returned 404. Republishing the registry record would change nothing there.

Our Claude Code plugin sits in a similar waiting room. Plugins are submitted through a form, and the public community marketplace catalogue is a read-only mirror, synced nightly from Anthropic's review pipeline, of the plugins that passed automated security scanning and were approved. Ours was submitted on September 7, shown as awaiting review on September 8, and still absent from that catalogue on September 14.

Claude connectors: ten minutes, then an inventory problem

The Claude connectors directory is a different destination from the Claude Code plugin marketplace. Remote servers are submitted from an organization's admin settings, through a portal that connects to the server. Our connector listing appeared about ten minutes after we submitted it on September 8, while the plugin was still waiting. Its tier is community, and that is the word we use.

Then we read the published inventory and found our own mistake. The directory's public record listed 120 tool names and left out an entire tool family, the one behind push notifications and analytics, while the description we wrote advertised both. The portal syncs the tool list from the server through the connection made at submission, and our connection did not expose that family. The description is ours to edit from the dashboard; the tool list is not an editable field, and changing it goes through the review team. Either way, the fix is ours.

For someone following the Claude connection guide, the only question that matters is whether the tools they get cover the task they came for. A directory listing does not change the tools a connection exposes, so the check we owe that reader goes beyond the listing: the published inventory against the description, then a real connection.

mcp.so: HTTP 200, application-level failure

The Save button from the opening was on mcp.so. We were updating an existing listing whose transport and overview had gone stale.

On September 8 the edit request returned HTTP 200, and its body carried application code -1, an "Invalid submission" message and a validation error under fieldErrors.tagline. The old tagline was too long. The form had no field to fix it and showed no error.

We sent the edit again with a shorter tagline, then read the public page, because a save response is a claim, not a result. On September 14 the listing showed Streamable HTTP, OAuth and the updated overview.

If that sounds familiar, it is the write-safety piece in miniature, with a web form in place of an agent. The green request in the network panel meant an HTTP exchange had completed, nothing more. Read the body, then read the page.

MCP Market: fast, paid, and one button to check

On September 8 we paid $69 for the remote-server "Official" listing option, which is a different product from the GitHub-repository submission. The listing was live the next morning, inside the advertised 24 hours, with the badge and the categories we asked for.

Search MCP Market for GoodBarber and a second card shows up next to ours: GoodBarber Skills, filed under Marketing Automation.

Then we clicked Try Now.

We had submitted our MCP product page as the destination. The published button led to our app-creation page, with MCP Market campaign parameters added, and still did on September 14. Both pages are ours, and it matters anyway: someone looking for connection instructions lands on a different step of the product journey.

Paying got the listing published fast. Checking where it sends people stayed our job.

Smithery and skills.sh: read what the signal measures

On Smithery, verification happens in the server's settings, through what its publishing guide calls an automatic official-vendor verification checklist. Our domain and backlink proofs passed their recheck on September 8. The public data embedded in the listing page said verified: false afterwards, and still did on September 14. The guide names the checklist without listing its items, and nothing we could see explains the step between two passed proofs and a false flag. We write down both states rather than calling the whole thing verified.

skills.sh showed our 44 skills on September 14, with installation counts. There is nothing to submit there: skills appear through the anonymous install telemetry of its CLI, when people run npx skills add. Those skills are instruction packages for using the server, and the counter measures installs: not a completed workflow, and not an OAuth flow that works in every client.

The September 14 snapshot

Every state below was checked on September 14, 2026; submission and publication dates are the real ones. Read "pending" as pending, and "absent" as unexplained.

Directory or catalogue	Admission mechanism	Observed delay	State on September 14	Pitfall
Official MCP Registry	Namespace authentication, metadata validation	Entry since April 28; 1.2.1 on September 7	Version 1.2.1 active and latest	Curation is left to aggregators
Glama	Registry import, ownership claim, health checks	Initial import not timed	Ownership verified; Healthy	Ownership and health are separate signals
awesome-remote-mcp-servers	Endpoint CI without credentials, Glama connector badge, PR	Same day, September 8	PR #4 merged	The probe stops at the 401
MCP.Directory	Registry auto-discovery; GitHub-based form with a 24-hour review promise	September 8 to 14, unresolved	No GoodBarber URL in sitemap	The form expects a GitHub repository
Gemini CLI gallery	Topic crawl, root manifest, validation	September 9 to 14, unresolved	No entry on the gallery page	A daily crawl gives no per-repo result
GitHub MCP gallery	Manual curation, then version sync	September 8 to 14, unresolved	Expected URL returns 404	Registry publication does not grant admission
Claude Code community marketplace	Submission form, security scan, approval, nightly mirror	September 7 to 14, unpublished	Absent from public catalogue	Separate from the connectors directory
Claude connectors directory	Admin portal; tools synced from the connected server	About 10 minutes, September 8	Community listing; 120 declared tools, no push or analytics	The synced tools did not match our description
mcp.so	Authenticated form and API validation	Update completed September 8	Corrected transport and overview live	HTTP 200 carried a validation failure
MCP Market	Paid remote-server submission	Live the next morning, September 9	Official listing live; a GoodBarber Skills card also listed	Try Now destination changed
Smithery	Official-vendor verification checklist	Proofs passed September 8	Public data still says `verified: false`	Passed proofs did not flip the public flag
skills.sh	No submission; CLI install telemetry	First install not timed	44 skills listed	Installs are not workflow success
Docker MCP Catalog	Remote-server PR, Docker team review, test credentials by form	Open since September 8	PR #4968 open; 0 comments	Review outcome unknown
VoltAgent skills list	Skills-list PR; rules require real community usage	September 8 to 14	PR #1031 closed without merge or comment	Adoption comes before the listing
BehiSecc skills list	Skills-list PR	Open since September 8	PR #689 open; 0 comments	Skills listings have their own review
Cline marketplace	Submission issue; review of adoption, credibility, maturity, security	Open since September 9	Issue #2492 open; 0 comments	Review weighs community adoption

The order we would follow next time

Start with the official registry, and with one description, one endpoint, one product page and one documentation URL, the same everywhere. Separate the hosted server from the skills package before choosing routes: some submission forms start with a GitHub repository, and a hosted server has nothing to put in that field.

Then read each gate before you submit. Replay public CI checks. If an agent prepares the PR, use the documented agent fast track. For a crawler, check the topic and the manifest. For a curated catalogue, read the acceptance criteria first, since some weigh community adoption, then keep the submission reference and wait for evidence of admission.

After publication, read what went live: the tool inventory, the authentication metadata, every destination link. Keep dates next to results and recheck weekly. The merged PR, the badge and the live page can tell three different stories.

All of it points to one page, the connection guide. If you are connecting GoodBarber to an assistant, start there.

One more thing: that was a dense week, and these procedures move fast. What you read above comes from each directory's own documentation where it has one, and from what we saw on the forms otherwise, checked on September 14. If you run one of these directories and something here is wrong, or already out of date, tell us in the comments.

Which check caught a mismatch in your own listing: the response body, the tool inventory, or the link after publication? Genuinely curious.

The URL on the flyer doesn't know your app changed

Dominique Siacci — Tue, 15 Sep 2026 14:29:50 +0000

A link leaves your system the moment it's printed. The QR code on a restaurant's counter card, the URL at the bottom of a club's poster, the link a shop put on its packaging three seasons ago — none of these can be recalled. You can't redirect ink. Whoever scans that code has an appointment with your app, and they chose the date: maybe this afternoon, maybe in four years, long after the app was redesigned twice and the section it pointed to was renamed.

A link is a promise. And the inconvenient part of the promise is that its duration was never yours to choose.

One door, many keys

Links reach an app from more places than anyone plans for: a QR code, a push notification, a URL shared in a chat, a link inside the app's own pages, another app handing over an address. Every one of those arrives shaped differently.

Our answer is architectural: all of them funnel into a single resolver. Whatever the source, the link is first translated into the same internal representation — what is being asked for, in which section — and only then does anything happen. The variety of doors is a parsing problem at the edge; behind the edge there's one door, and one promise to keep.

Formats get added. They don't get retired.

Over the years, the shape of our links has changed — of course it has: URLs got cleaner, more readable, more shareable. Each generation was an improvement, and each one created the same obligation: every link emitted in the old shape was already out in the world, printed and pinned and bookmarked.

So the rule is simple and it only goes one direction: formats get added, never retired. A link built the way we built them years ago still resolves in the app that ships today — not because that old parsing code is anyone's pride, but because the alternative is breaking a promise someone else is still holding. Backward compatibility of this kind isn't a feature you announce; it's debt you carry with a straight face, because the person who scanned yesterday's format doesn't know it's yesterday's, and shouldn't have to.

Durable by construction

Honoring old links forever would be impossible if a link depended on things that change. So the durability is built into the addressing, not into a policy of never changing anything.

A link targets a section by a stable identifier — never by its position in a menu. Reorder the navigation, redesign every screen: the identifier doesn't move, so the link doesn't care. Renamed a section's public URL? Where the platform can, the old slug is absorbed by a permanent redirect to the new one. Even the domain gets the benefit of the doubt: a link is matched with and without www, in http as well as https — so a flyer printed back when the web still said http:// opens today's app without noticing what decade it is. None of these tricks is clever on its own; it's the ordinary toolbox of URL hygiene. The only discipline is in refusing to skip any of it, anywhere, ever.

The pattern behind all of it: everything around an app changes over three years — the design, the structure, the web's own defaults. The address layer is built so that nothing a link relies on is among the things that changed.

When the promise can't be kept

Sometimes resolution genuinely fails — the section is gone, the content deleted. What happens next depends on where the link came from, and the distinction matters.

Inside the app, a link that resolves to nothing is a bug, and it gets treated like one: a not-found screen, visible enough that someone fixes it.

But a link arriving from the outside world — the flyer, the QR in the street — never ends on a dead end. As a last resort, when every attempt at resolution has failed, the visitor lands on the app's home. Not because errors should be hidden, but because of who's standing there: this person didn't hit a bug, they exercised an old promise. Handing them an error page punishes them for our history. Handing them the home screen at least honors the half of the promise that's left — there is an app here, and you're welcome in it.

You don't control when a link will be redeemed. You only control whether, on that day, it's honored. Build for the second, because the first was never up to you.