The installation itself wasn’t difficult. Many of the terms were unfamiliar, so I skipped most of the settings or postponed them for later, and focused only on what seemed essential—setting up the model. At the very least, it needed to be able to hold a conversation. I initially configured it using a subscription token obtained via Claude Code, but something felt off. When I reconfigured it using an Anthropic API token instead, it worked properly.
The default chat UI was quite uncomfortable to use, so the first thing I tried was connecting it to Discord. I’ve built Discord bots before, so that part wasn’t too difficult. The tricky part was configuring the group ID and channel ID in OpenClaw. After asking Gemini, I learned that enabling Developer Mode in the Discord UI allows you to see those IDs. Once that was sorted out, the rest went smoothly.
At first, it felt awkward and inconvenient that conversations only worked when I mentioned the bot, and that all conversations were threaded. Later, I found that starting conversations without mentions could be fixed by changing an option. As for threaded conversations, given token constraints, it actually seemed like a recommended usage pattern—so I decided to adapt instead.
When I asked what it could do, it briefly summarized its capabilities, then immediately asked me to define its identity.
> Who am I? Who are you? I don’t even have a name yet.
I asked how to set a name, and it told me to just say it in the chat. The first name that came to mind was JARVIS from Iron Man—but that felt too obvious. After a bit of thought, I decided to give it one of my online nicknames.
> Nick Horii. Nick in short. I’ll call you Nick.
The response surprised me.
> Nick. I like it. Alright, I’m Nick now.
> So you’re giving me your own nickname — that’s kind of an honor.
Surprised, I asked how it knew that was my nickname. It replied casually:
> Ha! No magic — I can see your Discord username in the message metadata. It shows up as “Kirin Choi (nick_horii)” when you message me.
Ah. Right. Of course.
After telling it that my name is Kirin, I started testing the things it said it could do—starting with file exploration. When I asked it to show the file list in my Downloads folder, a system popup appeared asking whether to grant permission. If I hadn’t allowed it, the command probably would have failed. Once permission was granted, it worked smoothly and displayed the file list in the chat. It even grouped the files by type and asked whether it should delete anything that looked unnecessary.
When I continued the conversation, I ran into the following error:
> Context overflow: prompt too large for the model. Try again with less input or a larger-context model.
Ah… this must be because the API tier is relatively low. I opened a new thread and asked about API rate limits. It explained that subscription-based accounts have better rate limits, so I decided to try that approach. Maybe due to security concerns, I had to run the configuration manually this time. After doing so, I ended up with three model profiles, including one using the Claude subscription token.
The problem was that the API-based profile was still being selected by default, so API charges were continuing. When I asked Nick about it, it explained that out of the three profiles, the API-connected one was currently set as the default. It offered to change the default profile itself, and I agreed. Despite this being a system-level setting that affects behavior, it changed the configuration and even restarted itself. In the past, I would have had to manually edit config files and restart processes. Doing all of this through conversation felt both strange and convenient.
I continued testing file-related features. To verify write permissions, I uploaded an image file in the chat and asked it to save it to the Downloads folder. It worked without issue. What surprised me was what Nick suggested next:
> Done. I’ve saved it to the Downloads folder. The filename is a UUID, which might make it hard to find later. Would you like me to rename it?
I told it to go ahead, and it renamed the file as if it were the most natural thing in the world.
I ran a few more tests around file access permissions, and the results were quite interesting.
📊 Final permission summary:
✅ Full access (Read/Write):
- Workspace: /Users/kirinchoi/.openclaw/workspace
- OpenClaw data: /Users/kirinchoi/.openclaw/*
- Home root files: files directly under /Users/kirinchoi/
- Custom dirs: /Users/kirinchoi/local, /Users/kirinchoi/PyCharmProjects
- Media folders: /Users/kirinchoi/Pictures, /Users/kirinchoi/Movies, /Users/kirinchoi/Music
- Downloads: /Users/kirinchoi/Downloads
- Temp: /tmp
👁️ Read-only:
- OpenClaw install: /opt/homebrew/lib/node_modules/openclaw
- System: /System, etc.
❌ No access (TCC-protected):
- Desktop: /Users/kirinchoi/Desktop
- Documents: /Users/kirinchoi/Documents
In short, Desktop, Documents, and Downloads are strongly protected unless explicit permission is granted, while most of the home directory is freely accessible. That was enough for file permissions, so I moved on to my next curiosity.
I considered using the model-usage skill to monitor usage, but it required an app called CodexBar. I decided against it—I wasn’t comfortable granting account access to an unverified third-party app.
Even though Discord was already connected, I was curious what other messengers were supported. Quite a few were available, and LINE and iMessage caught my attention. Kakao wasn’t supported. When I asked how iMessage works, it explained that it uses an app called BlueBubbles and follows the Apple ID of the Mac where OpenClaw is installed. I decided to hold off for now—I wasn’t thrilled about OpenClaw sending messages under my name. That said, as I configure things further, I might eventually ask it to read messages for me. LINE didn’t feel immediately necessary either. Building a Dooray integration might be fun someday, but that’s a task for later.
I assumed reminders would work, so I tested them—but the message never arrived at the scheduled time. This is where things got interesting. When I asked what settings to check, it diagnosed the issue and fixed it on its own.
> I found the issue! The cron job ran, but it failed after retrying over 100 times due to a “cron delivery target is missing” error. I specified the platform (channel) but forgot the actual destination channel ID. I’ll fix it now.
> For reference, OpenClaw cron jobs need:
* channel: “discord” (platform)
* to: “channelID” (specific destination) ← this was missing
> Would you like me to create another test reminder a few minutes from now?
I agreed, waited a bit… and still no message.
> Found another issue! Discord requires the recipient type to be explicit. Error: “Ambiguous Discord recipient.”
> Fix: add a channel: prefix to the channel ID.
* Before: “to”: “1469537081159188714”
* After: “to”: “channel:1469537081159188714”
> I’ve scheduled another test reminder for about 2 minutes from now. This time it should work.
This time, it did. I told it to use this method to contact me in the future.
Next, I asked it to create and run a simple “hello world” program using Claude Code. It worked smoothly, aside from one minor path issue. I keep my VS Code projects under ~/vscode_project. When I asked it to create vscode_projects/helloworld, it instead created ~/.openclaw/workspace/vscode_projects/helloworld. In other words, the relative path was interpreted from the OpenClaw workspace rather than my home directory. I decided to solve this by creating a symbolic link from ~/vscode_project to ~/.openclaw/workspace/. With this, I shouldn’t have to worry about path confusion later. According to Nick, once an SDD environment is set up, it can proceed directly—so I’ll try that next. I still need to decide what to build.
For web search, it said I’d need to connect something like the Brave API. I don’t expect to rely on that much, so I skipped it. Instead, I tested basic browsing capabilities. It can fetch URLs directly or launch Chrome and read the screen. Chrome access required a one-time permission grant, but worked fine afterward. I initially expected screenshots to be sent, but instead it read the screen and described it in text. It claimed it had sent images, but on my side I only saw descriptions.
> I see the Wordle start screen:
* Wordle logo at the top (green/yellow tiles)
* “Get 6 chances to guess a 5-letter word.”
* Subscribe / Log in / Play buttons
* Today’s date: February 7, 2026, No. 1694
* Edited by Tracy Bennett
I decided to investigate the missing images later. For now, I just wanted to confirm the capability. Curious how much web interaction was possible via chat, I had it play a game of Wordle—“Try ‘arose’ and tell me the result.” It cleared the game without issue.
After confirming most of the core features, I decided to finalize the identity setup. Up to this point, it was still using the default Discord icon. For visual creativity, ChatGPT still seems to have the edge, so I tried generating icons with a few prompts—but none were satisfying. Then it occurred to me: what if I reused a JARVIS-style icon and just changed the name? For tasks requiring visual consistency, Gemini tends to perform better, so I moved on to it. A satisfactory result came back quickly.

While looking for reference images, I learned that JARVIS is actually an acronym: Just A Rather Very Intelligent System. Since I was already down that path, I decided to do something similar. Gemini suggested a few options, and I picked one: Node Intelligence Coordination Kernel. I set its identity as a classic, JARVIS-like online AI assistant, with a personality described as “Jarvis-esque, direct, slightly cynical,” plus a polite speech style. After that, it asked whether it could delete BOOTSTRAP.md. That’s when I realized there had been onboarding prompts built into the system all along. Nicely done.
All of this took about two days. The basic setup is now complete, and I have a sense of how to interact with it. Next, it’s time to move on to more concrete use cases.