# mimic ships as mimic-client, imports as mimic, and admits one auth scheme it cannot beat

> littledivy/mimic captures traffic from an app you already use, extracts the session from it, and has a language model write a Python client that replays that session. Its own documentation says it is for your accounts, and it names the token scheme that defeats the whole approach.

**littledivy/mimic** — Intercept any app, then call it from Python like a library

- Repository: https://github.com/littledivy/mimic
- Stars: 2,068 · Forks: 198
- Language: Python
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/littledivy-mimic

## The package has three names and one dependency

The repository is called mimic. The distribution published to a package index is called mimic-client, which is also what the manual installation command uses. The library you import is mimic, and the command you type is mimic as well. Nothing about that is wrong, but it means a search for the tool by any one of the three names will not obviously find the other two, and it is worth checking which one a piece of documentation is referring to. The manifest itself is small. One runtime dependency, the HTTP library, one optional extra holding the proxy for capture, a floor of Python 3.9, and a version of 0.1.0. There are no published releases at all, so there is no tag to install from, and the version number has to be read out of the manifest.

## The boundary is drawn in the documentation, not left implicit

The project states its own scope in a short section, and the statement is narrow. It says to use the tool on your own accounts and data, that it replays your session, and that it is not a tool for accessing anyone else's, and it asks you to respect each app's terms of service. The licence repeats the same condition and adds that the software is provided as is with no warranty. That framing is consistent with how the tool works rather than bolted on afterwards, because the whole mechanism is replay of credentials you already hold. The generated client is described as reusing your captured session, and there is no login, no credential store and no account creation anywhere in the documented flow. If what you want is to reach an account that is not yours, this is not the tool, and the documentation says so before you install it.

## The client is written by a language model reading captured endpoints

The pipeline is three stages and the middle one is ordinary code. Traffic is captured through a proxy, the session is extracted from that traffic into a session object, and a language model reads the captured endpoints and writes the client. That last stage is not a template engine, which is why the install step checks for a command line coding tool as well as the proxy, and why the diagnostic command confirms both are ready. What comes out is a plain Python file built on the library's app base class, with named methods and body templates, meant to be edited like any other file in your project. It also handles the multi-step shape that mobile APIs tend to have, where one call fetches a token and the next spends it, so the generated code can chain those steps rather than making you orchestrate them.

## Capturing an iOS app is four steps and the third one is the one people miss

The record command starts the proxy and prints the phone steps, filling in your machine's address on the local network for you. On the phone you set the Wi-Fi proxy to manual and point it at that address and port, open a page at the proxy's certificate address and install the profile, then enable full trust for the proxy in the certificate trust settings. The documentation flags that third step as easy to miss and says nothing works without it, which is accurate: an installed profile is not a trusted root, and until it is trusted the device will refuse the connection in a way that looks like a network fault. After that you open the target app and use it normally, and the captured hosts appear in a listing command where you pick the API host you care about.

## Retries distinguish the calls that are safe to repeat

The session helpers cover the common HTTP verbs, return parsed JSON, and raise the HTTP library's own error type on a failed response, so nothing is swallowed. The interesting part is what happens when a token expires. On an idempotent request, a 401 triggers one automatic re-pull of the session from the proxy and a single retry. On a non-idempotent request, nothing is retried unless you pass an explicit refresh flag. That distinction is the difference between a library that quietly double-charges someone and one that does not, and it is unusual enough to be worth checking in any similar tool. Three ways to build a session are offered for people who do not want generated code: pull from the proxy's own web interface, paste a request copied as cURL from browser developer tools, or construct one from a base URL and a header dictionary by hand.

## Pinning blocks the capture; sender-constrained tokens block the model

The limitations section separates two failures that are often confused. Certificate pinning, in banking and social apps, means the app rejects the interception certificate, so the proxy sees nothing and the host list stays empty. That blocks capture only: the documentation is explicit that replay still works once you are past the pin, and it ships a command that sets up a bypass built on an instrumentation framework, with a separate document describing it. The second case has no such exit. Where each request carries a fresh proof signed by a key that never leaves the device, a captured request will not replay at all, and the documentation says this defeats the core model rather than just the capture step, with no clean workaround. The practical test is one command: if the host list shows the app's API host, the rest will work.

## Two capture backends need no proxy and no certificate

The proxy is only needed for apps without a web version. For anything you can reach in a browser there are two paths that avoid the phone, the certificate and the trust settings entirely. The first is copy as cURL from developer tools, pasted into a session constructor, which is one line of code from a request you already made. The second is the browser's own capture format: open the network panel, right-click a request, save everything as a file in that format, and point the tool at both the file and the host you want. The same format has a direct constructor as well, so a session can be built without going through the generation step at all. Both paths are described on the same terms as the proxy route, no proxy and no certificate, which makes them the obvious starting point for anyone who is not trying to intercept a phone.

## The install script brings its own package manager

Installation is one command, a shell script, and it does more than install this project. It installs a Python package manager if the machine does not already have it, then installs the tool into an isolated tool environment so it does not touch the system interpreter. The proxy is deliberately not part of that install: it is launched on demand through the tool runner the first time you record, so there is nothing extra to install and nothing to keep up to date. The manual route is a single package manager install of the distribution name instead, which is the option to take if you would rather not run a script from a repository you have not read:

```bash
sh install.sh
```
 The rest of the tree matches that shape: one install script, one package directory, a tests directory and a docs directory holding the two limitation write-ups.

## Conclusion

mimic suits someone automating an API they already have an account for, where a mobile app is the only client and the endpoint documentation does not exist. Two limits are worth weighing before anything else. It replays your session rather than logging in, so anything that binds a request to a device key will refuse it, and the project says plainly there is no clean workaround for that case. And it is scoped by its own authors to your own accounts and data, with the terms of service of each app left to you. Beyond that, the practical questions are whether you have the hardware to intercept a phone, and whether the generated client is one you can read and maintain, since the output is a Python file you are expected to edit.

## FAQ

### What is littledivy/mimic?

It is a tool that captures traffic from an app you already use, extracts the session from that traffic, and has a language model write a Python client that reuses it. You do not write the client yourself, and the generated file is ordinary Python you can edit. The distribution is published as mimic-client and imported as mimic.

### How do I install mimic?

Run sh install.sh, which installs a Python package manager if one is missing and then installs the tool into an isolated environment. The interception proxy is not installed at that point; it is launched on demand the first time you record. The manual alternative is a single tool install of mimic-client, and the diagnostic command mimic doctor confirms both the proxy and the coding tool are ready.

### What authentication schemes does mimic not work with?

Two, for different reasons. Certificate pinning stops the capture, because the app rejects the interception certificate and no host appears, though replay works once that is bypassed. Sender-constrained tokens, where each request carries a fresh proof signed by a key held on the device, stop replay itself, and the project states there is no clean workaround for that case.

### Can mimic capture an app without a proxy?

Yes, for anything with a web version. You can paste a request copied as cURL from developer tools into a session constructor, or save the browser's own capture file from the network panel and point the tool at that file and host. Both paths are described as needing no proxy and no certificate.

### How does mimic handle an expired token?

On an idempotent request a 401 triggers one automatic re-pull of the session from the proxy and a single retry. Non-idempotent requests are not retried unless you explicitly pass refresh=True, and the verb helpers raise the HTTP library's own error on a failed response rather than returning something quietly.

## Sources

- [Issues](https://github.com/littledivy/mimic/issues)
- [License: MIT](https://github.com/littledivy/mimic/blob/main/LICENSE)
- [littledivy/mimic on GitHub](https://github.com/littledivy/mimic)
- [README](https://github.com/littledivy/mimic/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/littledivy-mimic