Why? Multi-tenant environments. First, we need to understand a few differences between environments:

• End-user UI
• Agent Runtime Environment
• LLM Server

So

• When you run Claude Code on your local MacBook, the first two are always local. The third is usually the Claude.ai server.
• When you ssh to a virtual private server (VPS) and install Claude Code there, the first two are your remote server. The third is still the Claude.ai server.
• When you run Claude RC on your virtual private server and code from your iPad using the Claude app, the end-user UI is on your iPad, the agent runtime environment is on your VPS, and the server is still Claude.ai.

Most people physically separate their tenancy, such as Claude Code, from their personal vs. work laptops. So in most cases, it's not a big deal.

But when you need multi-tenancy, it becomes super stressful. For example, say you have two different toolkits:

• personal toolkits (personal Notion, personal Sentry, personal Linear)
• workplace toolkits (company Notion, company Sentry, company Linear)

Most MCP auth states or code harnesses don't support profiles, so you can only log in to one.

So therefore... a natural evolution was to have both:

• a personal VPS with all personal toolkits set up
• a workplace VPS with all workspace toolkits set up

to physically isolate tenancies.

Now we've solved the multiple-profile issue, but the client's problems persist. Now let's get back to the environments:

• End-user UI
• Agent Runtime Environment
• LLM Server

All MCP auth or toolkit auth info should always be saved in the Agent Runtime Environment IMHO. However, a surprising number of harnesses tie them to the LLM server (such as Codex Apps or Claude.ai Plugins) or put them in the end-user UI (Claude Desktop or Codex Desktop).

Now the problem is:

• If the auth data is put on the LLM server, you cannot reuse LLM accounts across tenants
• If the auth data is put on the end-user UI, you cannot use the same app to access multi-tenants.

The only way to reliably isolate different auth information is thus:

• You ssh to a virtual private server (VPS) and run Claude Code there. Never use LLM server plugins.

Then

• End-user UI
• Agent Runtime Environment

are both isolated VPS, and

• LLM Server holds no information on the tenancy

This way, you can provide different toolkits, creating multiple dev environments.

인하우스와 자유경쟁은 연구를 위한 두 가지 다른 방법으로 장단점이 명확하다. 인하우스는 더 많은 통제 권한과 비밀성을 보장해주지만 자유경쟁은 더 빠르고 더 저렴한 소비자 가격을 보장해준다. 이것을 개인적 맥락에서 적용해서 생각해볼 수 있을까?

• 인하우스. 민사고에서는 연구 자원이 제한되어 있어 기술 애호가를 찾기가 어려웠다. 다행히도 안티프래질하게 독창성을 기를 수 있었다.
• 자유경쟁. 대학은 학생들이 자금, 인정, 학문적 지위를 놓고 경쟁하는 자유 시장 경쟁 환경을 제공한다. 이는 혁신을 촉진하고 우수성을 장려하며 연구자와 학생을 위한 역동적이고 자극적인 환경을 조성한다. 대학에서 누릴 수 있는 최고의 이점.
• 인하우스. 기업 연구소는 수익과 혁신을 우선시한다. 이런 기업 연구소의 기술은 몇 년 앞서 있다. 예를 들어, Google의 내부 연구소는 경쟁 우위를 유지하기 위해 최첨단 연구를 공개하지 않고 있다. 이로 인해 개별 과학자 및 과학에 대한 우려가 제기된다. 그럼에도 여전히 독립적인 연구를 하기에 좋은 시기이다. 왜냐하면...
• 자유경쟁. 인터넷은 온라인 리소스에 대한 액세스를 통해 독립적인 과학자들의 과학 연구에 혁명을 일으키고 있다. 노트북과 인터넷 연결만 있으면 협업, 공유, 자금 조달, 과학 발전과 혁신에 대한 기여가 가능하다.

인터넷 기반의 자유경쟁 연구를 더 발전시키기 위해 더 나은 인프라가 필요할지도 모른다. 웹에서 사려 깊은 통찰과 연구를 작성하고 게시하는 것이 더 쉬워져야 한다. 이 Memex는 그 생각의 한 걸음이다.