# gpt-code-ui: make with no arguments uploads to PyPI, and the recommended pip line is missing a comma

> A self-hosted implementation of a chat interface that writes and executes Python, pairing a Flask API with a message queue and a browser interface on three ports. It runs generated code on your machine over HTTP, the readme describes no isolation, and the last commit to the default branch is dated 2024-03-20.

**ricklamers/gpt-code-ui** — GitHub describes it as An open source implementation of OpenAI's ChatGPT Code interpreter. The repository metadata lists Python as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/ricklamers/gpt-code-ui
- Stars: 3,531 · Forks: 420
- Language: Python
- License: MIT
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ricklamers-gpt-code-ui

## The recommended pip line cannot install as written

The readme offers one command to make the basic dependencies available, described as recommended. It has three problems:

```sh
pip install "numpy>=1.24,<1.25" "dateparser>=1.1,<1.2" "pandas>=1.5,<1.6" "geopandas>=0.13,<0.14" "tabulate>=0.9.0<1.0" "PyPDF2>=3.0,<3.1" "pdfminer>=20191125,<20191200" "pdfplumber>=0.9,<0.10" "matplotlib>=3.7,<3.8"
```

One specifier is missing its comma, so that constraint reads as a version followed by a comparison rather than a range. One window is dated with an upper bound of 20191200, which excludes the release immediately after the lower bound and so admits at most one version of that package. And the distribution is named without its suffix, which fetches a different package from the maintained line most people mean by that name. Nine requirements, three corrections, and this is the line the readme points people at first.

## Running make with no arguments publishes to the package index

The default target of the build file is not a build:

```
all: check_env_var build upload_pypi
```

So typing make in a fresh clone checks an environment variable, compiles the frontend, builds the source and wheel distributions, and then uploads them with a package publishing tool. There is no confirmation prompt, no dry run and no check that the version has changed. Two of the three newest releases were published on the same afternoon, minutes apart, which is what a version-bump script run twice looks like. For a maintainer that is a convenience. For anyone who clones the repository to read the code and types the one word the readme implies, it is a publish. The upload target has no guard of its own; the only thing standing between a clone and the index is the environment check described next.

## The guard that blocks the build is the variable local development needs

The guard is called check_env_var and it does the opposite of what its name suggests:

```
check_env_var:
ifeq ($(VITE_WEB_ADDRESS),)
	@echo "VITE_WEB_ADDRESS not set, proceeding..."
else
	$(error "VITE_WEB_ADDRESS is set, aborting...")
endif
```

If the variable is empty, the build proceeds. If it is set, make stops with an error. The intent is sensible: that variable points the frontend at a development address, so a build made with it set would publish a web interface pointed at the maintainer's laptop. The naming is the problem. A target called check_env_var reading as a check for a required variable is the opposite of what it is, and it is the only thing standing between the default target and a publish. Every target that depends on it inherits the rule, so the build and the publish are equally blocked, which means the convenient path to testing a local frontend build is to work outside the build file.

## It executes generated Python over HTTP, and the readme says nothing about isolation

Set the pieces together and the security surface is not subtle. The feature list says the tool generates code and runs it, in a Python kernel. The dependencies include an in-process kernel package and a message queue, and the example configuration opens three ports: one for the application programming interface, one for the web interface, and one for the queue. The feature list also includes file upload. So this is a web service that accepts a file, asks a model to write code, and executes that code on the machine it is running on, reachable over three listening ports. The readme discusses none of that: no mention of sandboxing, no mention of binding addresses, no warning that a model response is untrusted input. That silence is the finding. The readme's own framing is friendly, ending by asking for contributions and promising to try to be responsive, and it was last updated on 2024-03-20.

## The frontend build deletes the Python package's data directory

The frontend is not a separate artefact. It is package data, and the build replaces it:

```
find ../gpt_code_ui/webapp/static -mindepth 1 ! -name '.gitignore' -delete && \
rsync -av dist/ ../gpt_code_ui/webapp/static
```

So the compiled interface is compiled into the Python distribution, and each frontend build deletes everything in that directory except a single ignore file before copying the new build across. That is a defensible way to keep a Python wheel and a browser bundle in sync, and it is also why the packaging metadata lists static paths as package data. The consequence is that the repository's own checked-in static files are not source of record. The version shown in the interface is injected from the packaging file at build time through an environment variable read with a grep pattern, which means the frontend and the package can only ever agree if both builds run from the same checkout.

## The client dependency is pinned below version 1 and the config is from 2023

The packaging file requires the model client at a floor and a ceiling:

```
'openai>=0.25,<1',
```

A floor of 0.25 with a ceiling of 1 is the pre-1.0 client line, and the example configuration matches it, carrying an API type variable, an API base variable, and an API version pinned to a dated preview value from March 2023. Three of the newest releases are all in the same 0.42 line, published within four days of each other in July 2023, and the default branch has not been pushed since March 2024. So the whole stack is shaped around a client generation from three years ago. A Flask dependency below version 3 and a kernel dependency below version 7 sit alongside it. None of this makes the project unusable, and the code is small enough to read, but anyone picking it up today should expect the dependency work to be the first task rather than an afterthought.

## The feature list names two models that the configuration actually controls

The features section advertises model switching between GPT-3.5 and GPT-4. The mechanism is an environment variable holding a JSON array:

```
OPENAI_MODELS=[{"displayName": "GPT-3.5", "name": "gpt-3.5-turbo"}, {"displayName": "GPT-4", "name": "gpt-4"}]
```

So the model list is configuration, not code, which means adding a model is an edit to a dotenv file rather than a change to the interface. The feature list is describing a snapshot of that file rather than a capability, and it will read as out of date the moment anyone changes the variable. The same file also carries commented-out entries for extra headers and for a debug log level, which is the project's way of documenting optional settings. One limitation is stated honestly elsewhere in the readme: model selection in the interface is not supported when the service is Azure, which is a real gap given that a separate example configuration exists for it.

## Getting a starter configuration means cloning the repository

The configuration section says you can use the example environment file in the repository, and adds a parenthetical instruction: make sure you clone the repository to get the file first. That is the whole setup path, and it means a user who installed the package from the index and wants to configure it still has to clone the source. The sequence given is to copy the example to a dotenv file, edit it, and run the tool. There are two example files, one for the standard service and one for Azure, and the Azure one carries the deployment-name variables that the standard one does not. The readme also notes that the base URL variable for changing the endpoint includes the protocol prefix, which is the kind of detail that costs an afternoon when guessed wrong. None of this is exotic; it is just a project whose documented setup assumes you have the source tree.

## Conclusion

Run it on a machine you are willing to lose, on a network you control, and treat every model response as untrusted input that will be executed. That is the decision, and it is not a documentation problem, it is the design: the tool exists to run generated code locally, so the blast radius is your host. Three further checks. The default make target publishes to the package index, so never run it without arguments in a clone. The dependency line the readme calls recommended cannot install as written, so expect to correct the version specifiers yourself. And the last commit to the default branch is dated 2024-03-20, with the newest release from July 2023 and the client dependency pinned below version 1, so plan to spend time on compatibility rather than assuming a maintained package.

## FAQ

### What does the gpt-code-ui project do?

It is an open source implementation of a chat interface that generates and executes Python. The feature list covers file upload and download, context awareness across previous messages, code generation, running the code in a Python kernel, and switching between models. It ships as a command that starts a Flask application, a message queue and a browser interface on three ports.

### How do I install and configure gpt-code-ui?

Install the package from the index and run the command. Configuration comes from a dotenv file in the working directory, and the readme directs you to clone the repository to obtain the example file. Copy it to a dotenv file, put your key in it, and adjust the port variables or the base URL variable if your setup differs. A separate example file covers Azure deployments.

### Does gpt-code-ui have a Docker image?

Not in this repository. The readme credits a separate organisation with the effort of bundling the Python package into a container and links to that project instead. The repository's own build file targets the package index and the frontend, and the container work lives elsewhere.

### Is gpt-code-ui still maintained?

The default branch was last pushed on 2024-03-20. The three newest releases are from July 2023, with two of them published minutes apart on the same afternoon. The readme asks for contributions and says the project should be a community initiative, and the client dependency is pinned below version 1, so expect to do compatibility work yourself.

## Sources

- [Official README](https://github.com/ricklamers/gpt-code-ui#readme)
- [Project repository](https://github.com/ricklamers/gpt-code-ui)
- [Release notes](https://github.com/ricklamers/gpt-code-ui/releases)

---

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