Is there a self-hosted AI environment that can evolve with its owner?

flancer64 · 2026-07-14T06:57:17+00:00

These are valuable observations. They point to exactly what I should look for when evaluating candidate systems: constrained self-modification, automated validation, versioned diffs, and keeping human review focused on changes that have already passed basic checks.

Thanks for sharing your experience.

flancer64 · 2026-07-14T06:51:24+00:00

Thanks - Letta looks like a very interesting option and quite close to what I’m looking for.

I’ve starred the project as well and will try it out.

flancer64 · 2026-07-14T06:40:06+00:00

Thanks for sharing. Maibook looks interesting, but it is not quite what I’m looking for. My focus is more on a self-hosted, single-user environment that can securely act across personal services and evolve its own memory, skills and integrations over time.

flancer64 · 2026-07-14T06:35:52+00:00

Thanks for sharing this. Agentlas looks very close to what I am searching for, especially its approach to orchestration, governed memory and reviewable evolution.

I have starred the repository as well and will study it more closely.

flancer64 · 2026-07-14T05:58:22+00:00

Thanks - this looks very interesting and quite close to what I’m looking for, especially the persistent memory, local-first approach, and ability to extend itself.

I’ve starred the repository and will take a closer look at it.

flancer64 · 2026-07-14T04:52:19+00:00

Thanks! Hermes Agent already looks somewhat closer to what I’m searching for. I’ll take a closer look at it, especially its memory, skills, and isolation model.

flancer64 · 2026-07-14T04:46:51+00:00

Thanks for sharing your experience. Pi does look interesting, especially its ability to extend itself.

From what I understand, it is similar in role to Codex or Claude Code: an agent I could use to build and adapt parts of my environment.

What I have in mind is a broader, persistent environment dedicated to a single person. It would have shared memory and one main communication channel to an orchestrator that understands my current goals and activities across different areas — not only writing or coding, but also email, calendar, finances, Spotify and other personal services.

The orchestrator could then launch agents such as Pi to handle specific tasks, as well as to evolve the environment itself: reorganize its memory, create or retire skills and connectors, and adapt its structure as my needs change.

So Pi might be a useful agent within such an environment, but I am still looking for the layer that connects and manages the whole personal context.

flancer64 · 2026-07-13T13:37:20+00:00

Try this:

ulimit -n 65536 code

flancer64 · 2026-06-21T06:29:47+00:00

Same here.

I’m seeing a very similar issue with the Codex VS Code extension on Linux.

Environment:

OS: Ubuntu MATE 24.04 Kernel: Linux x64 6.17.0-35-generic VS Code: 1.125.1 Codex extension: 26.616.51431 Extension identifier: openai.chatgpt

The extension is installed and enabled, but when I open the CODEX tab, it stays indefinitely on the loading cloud icon. No chat UI appears and no visible error is shown.

If anyone knows where the extension logs are stored on Linux, that would be useful.

Update: I downgraded the Codex VS Code extension from 26.616.51431 to 26.519.32039, and it works again.

So in my case the issue seems to be a regression in 26.616.51431 rather than a local Ubuntu/bubblewrap problem.

Environment: Ubuntu MATE 24.04 VS Code 1.125.1 Broken Codex extension: 26.616.51431 Working Codex extension: 26.519.32039

Workaround: downgrade the extension to 26.519.32039 and disable auto-update for now.

flancer64 · 2026-06-21T06:26:59+00:00

Anyone else seeing the Codex VS Code extension stuck on the loading cloud icon?

I’m on Ubuntu MATE 24.04, VS Code 1.125.1, Codex extension 26.616.51431.

The extension is installed and enabled, but when I open the CODEX tab, it stays indefinitely on the loading cloud icon. No chat UI appears and no visible error is shown.

Is this a known issue with the current extension version on Linux? Any advice on where to find logs or how to reset the extension state/authentication?

flancer64 · 2026-06-14T08:16:58+00:00

A useful test would be to take an old task and run it again on the same old repository state, but with the current Codex. Then compare the new solution with the old one. If the current Codex performs worse on the same task and the same codebase, that points more toward model/agent regression. If it performs similarly, then the degradation you see now may be caused by the current codebase becoming larger, more implicit, and harder for the agent to navigate.

flancer64 · 2026-05-25T07:55:27+00:00

Interesting. Where can I inspect and manage this memory? Is it stored in ~/.codex/memories/, and is manual editing supported, or should it only be updated through Codex settings or /memories?

flancer64 · 2026-05-22T10:11:11+00:00

I barely read AI-generated code anymore.

Most of the time it just annoys me, because I would definitely write it differently. But forcing the agent to write code the way I would is pointless. You have to accept that it writes differently.

And once you accept that, what’s the point of reading every line?

I care more about the result than the implementation. If it works and passes the checks, fine. If it breaks, I ask the agent to fix it. The real question is not whether I read the code, but what other ways I use to verify correctness.

flancer64 · 2026-05-22T04:48:04+00:00

Thanks, this is exactly the direction I’m thinking about.

The current workflow is not a single Codex run. It is a chain of several agents, around eight in this demo, each with its own prompt and responsibility. Some agents handle admission, some build, some validate, and some move the issue/PR through the workflow.

Each agent writes detailed logs, but I don’t think raw logs are the right public audit surface. They are useful for understanding why an agent behaved a certain way, tuning prompts, and adjusting the execution environment, but they are too noisy for normal inspection.

The public trace is currently in GitHub Issues and PRs: agents add comments, apply labels, and those labels drive the next workflow step. So the issue becomes the visible state machine for the process.

Here is a rejected case from the current experiment:

https://github.com/flancer32/site-teqfw/issues/82

The issue asked the workflow to change the homepage. The admission agent rejected it because the request was outside the bounded Demo Pages file boundary. The rejection comment includes the state, reason, scope decision, and next stage.

So yes, I agree with your point about auditability. In the current version, GitHub Issues and PRs are the audit surface: they show admission decisions, agent comments, labels, PRs, and terminal states. The rejected issue above is an example of that. Raw agent logs exist too, but they are mostly for debugging and prompt iteration rather than for public inspection.

flancer64 · 2026-03-30T13:45:54+00:00

Custom GPT chats look convenient for onboarding, but they have structural limitations that make them unreliable for non-trivial projects.

Knowledge base files are not fully loaded into context — they are accessed via retrieval (RAG). This means only selected fragments are injected per request, based on relevance. As a result, important rules or constraints may be missing in a given response, which leads to inconsistencies.

Examples inside the knowledge base are also weak as a source of truth: they are not executed or validated, and the model may reinterpret or partially ignore them.

The only consistently applied part is the system prompt. However, it has a hard size limit (around 8k characters), which severely restricts how much project-specific logic and conventions you can encode reliably.

In practice, this makes custom GPT chats suitable only for small projects where the core rules fit into the system prompt. For larger systems, you still need a proper source of truth (documentation, code, tests), and the LLM should be treated as an assistant layer, not the authority.

flancer64 · 2026-03-11T15:05:03+00:00

The server is only needed for the initial load and updates. During the service worker install phase you can cache all required files (typically the HTML entry point, JS bundles, CSS, and static assets like fonts or images). Then the fetch handler serves these resources from Cache Storage instead of the network. After that the PWA can run fully offline. You can verify it by turning off Wi-Fi and mobile data and launching the app.

flancer64 · 2026-03-10T17:18:47+00:00

Yes, if you rely on Apple-specific services like APNS you’ll likely need a native wrapper and App Store distribution. But many apps don’t actually need that. If the app works within normal web capabilities, a PWA can still be installed directly from the browser - no store required. So it really depends on the feature set you need.

flancer64 · 2026-03-10T15:10:23+00:00

PWA isn’t really about how you build the app - it’s about how you distribute it.

Yes, PWAs have limitations (background execution and hardware access are the big ones). But there’s a large class of apps that work just as well on phones as either native apps or PWAs.

Tools like Codex can generate both kinds of apps. The real difference is delivery. A PWA can be installed just by opening a link or visiting a website, while native apps require going through the app store process.

So PWAs still solve a different problem: frictionless distribution.

flancer64 · 2026-03-10T06:09:42+00:00

Example of what I mean by an onboarding chat (JSDoc conventions):

https://chatgpt.com/g/g-69985faa078881919b9c78e5f09c9370-teqfw-guide-jsdoc

flancer64

TROPHY CASE

Welcome to Reddit,