A follow-up to the OpenClaw autonomous agent post. This time: no Mac mini, no framework, no terminal. Just Claude, a Chrome extension, and a conversation that builds a fully functional Oracle APEX dashboard with live weather, crypto, news, maps, and market data.
In my last post, I walked through a fairly involved setup: a dedicated Mac mini, a macOS user account for the agent, OpenClaw as the orchestration framework, Slack for communication, soul files, heartbeats, cron jobs — the works. That setup is powerful. It gives you a 24/7 autonomous agent that can do things while you sleep.
But what if you don't want all that? What if you just want to sit down, have a conversation with an AI, and watch it build something in your browser — right now, on your machine, no infrastructure required?
That's exactly what I did this time. Anthropic recently released a Chrome extension for Claude that gives it the ability to see and interact with your browser. Pair that with a Claude Max subscription (which gives you access to Claude Opus 4), and you have something remarkable: an AI that can navigate web applications, click buttons, fill out forms, read pages, and execute JavaScript — all through your own Chrome browser, guided by a natural language conversation.
No servers. No framework. No dedicated machine. Just you, Claude, and a chat window.
The result is Dashboard Hub — a fully functional, live-data dashboard built entirely inside Oracle APEX. It includes:
All APIs are free and require no authentication keys. The entire dashboard runs client-side with JavaScript, fetching data on page load.
Here's what you need:
| Component | Detail |
|---|---|
| Browser | Google Chrome |
| Extension | Claude Chrome Extension (by Anthropic) |
| Subscription | Claude Max ($100/month for Opus 4 access) |
| APEX Account | Free tier at oracleapex.com |
That's it. You install the extension, open your APEX workspace, and start talking. Claude can see your screen, read the DOM, click elements, type into fields, and run JavaScript in the page context. It's like pair programming, except your partner has read every Stack Overflow answer ever written and doesn't need coffee breaks.
I didn't write a spec. I didn't create wireframes. I literally said:
"Create a new APEX app that shows a dashboard, with newsfeed with the latest news from a real site API that is free, weather, crypto, stocks and all the good stuff you usually see in a dashboard, put a map, etc."
And Claude got to work.
Watch the app here: Dashboard-Hub
It started by navigating to the APEX App Builder, clicking "Create", typing "Dashboard Hub" as the application name, and creating the app. Then it opened Page 1 in the Page Designer, created a Static Content region, and started building.
The whole process was a back-and-forth. Not because Claude needed hand-holding, but because APEX's Page Designer is genuinely complex, and some approaches that seemed obvious turned out to have hidden limitations. Watching Claude navigate those obstacles in real-time was the most interesting part of the entire experiment.
This is the part I want to be honest about, because I think it's the most valuable takeaway for anyone experimenting with AI-assisted development.
If I were building this dashboard myself as an experienced APEX developer, I would do it very differently. I'd use native APEX components: Classic Reports or Cards regions backed by SQL queries, APEX charts for the crypto and market data, a Map region for the map, Template Components for the news cards, and page-level CSS/JS file references managed properly. I'd use Application Items and Application Processes for any server-side API calls. I'd probably use REST Data Sources to pull from the external APIs and bind them to report regions declaratively.
Claude did none of that.
Instead, it created a single Static Content region and stuffed the entire dashboard into it: HTML structure, CSS styles, and JavaScript — living together in one region's HTML Code field and the page-level "Execute when Page Loads" property. It's essentially a standalone single-page app that happens to be hosted inside an APEX page.
Why? Because Claude is drawing from general web development knowledge, not APEX-specific expertise. It knows HTML, CSS, and JavaScript extremely well. It knows how to fetch data from APIs, manipulate the DOM, and build responsive layouts. When I said "build a dashboard," it reached for the tools it knows best, and those tools happen to work inside a Static Content region.
From a pure APEX perspective, this is not how you'd do it. But from a "get a working prototype in 30 minutes using AI" perspective? It's incredibly effective.
Here's the thing about APEX's Static Content region, it's both the simplest and the most flexible region type. It accepts raw HTML, and if you set the page-level JavaScript and CSS properties, you have a fully self-contained web application running inside the APEX framework. You get APEX's authentication, session management, navigation, and theming for free, while your content does whatever it wants inside the region body.
Is it the "APEX way"? No. Is it a valid approach for prototyping, proofs-of-concept, or dashboards that primarily consume external APIs? Absolutely.
Think of it like this, if APEX is a house, the Static Content region is a room where you're allowed to bring your own furniture. The house still provides the walls, the roof, and the plumbing (authentication, session, navigation). You're just decorating one room yourself.
One of the first real obstacles was Claude initially tried to type the full HTML+CSS+JavaScript code into the HTML Code editor using keyboard input. The APEX code editor (backed by Monaco) interpreted this as rapid keystrokes and duplicated content massively — the field ended up with over 227,000 characters. APEX threw an error, "Value too long by 195,106 characters!"
This is a scenario no human would encounter. You don't type 5,000 characters of code into a field letter by letter. You paste it. But Claude's type action simulates keystrokes, and Monaco's autocomplete and bracket-matching features turned a 5K block of code into a 227K mess.
How Claude adapted: It switched to using JavaScript to interact with Monaco directly — window.monaco.editor.getEditors()[0].setValue(code) — to set the content programmatically. When that still didn't persist changes to the APEX model, it discovered the pe object (APEX Page Designer's internal API) and used page.getProperty(id).setValue(value) to set properties directly through the model layer. This was a creative workaround that no documentation covers — Claude figured it out by inspecting the page's JavaScript objects in real-time.
Another surprise! APEX sanitizes the HTML Code field in Static Content regions. It strips <script> and <link> tags. This is a security feature — APEX doesn't want arbitrary scripts injected into regions because the same content could be edited by multiple developers.
Claude discovered this when the dashboard rendered the HTML and CSS, but none of the JavaScript executed. The solution: move JavaScript to the page-level "Execute when Page Loads" property (which is designed for JavaScript) and external library URLs to the page-level "JavaScript File URLs" and "CSS File URLs" properties.
This is actually the correct APEX pattern — page-level properties for JS/CSS, regions for HTML content. Claude arrived at the right answer, but through trial and error rather than prior knowledge.
This was the most fascinating part to watch. When clicking through the UI wasn't reliable enough for setting complex multi-line values, Claude started exploring the browser's JavaScript context. It found pe — the Page Designer's internal model object — and figured out how to:
It even discovered property IDs by trial and error: 15 for JavaScript File URLs, 17 for Execute when Page Loads, 45 for CSS File URLs. These aren't documented anywhere publicly. Claude found them by reading the property panel's DOM elements and correlating them with the model's internal structure.
This is the kind of thing that makes you pause and think about what's actually happening. The AI is not following a tutorial. It's reverse-engineering a proprietary internal API in real-time to solve a problem it encountered organically.
In the interest of being educational, here's how I'd build this dashboard "the APEX way" and why Claude's approach is still valid for its context:
APEX way: Create REST Data Sources for each API (Open-Meteo, CoinGecko, RSS2JSON). These are managed declaratively in Shared Components and can be bound to report regions, charts, or Template Components. Server-side calls mean no CORS issues and better error handling.
Claude's way: Client-side fetch() calls directly from the browser. This works because all the APIs chosen happen to support CORS and require no authentication. It's simpler, faster to implement, and perfectly fine for a dashboard, but wouldn't scale to APIs that require server-side secrets.
APEX way: Use APEX's grid layout system with multiple regions, each in its own column group. Use Template Options for responsive breakpoints. Use the Universal Theme's built-in card, badge, and report templates.
Claude's way: CSS Grid and Flexbox inside a single region, with custom CSS for the dark glassmorphism theme. This gives complete visual control but doesn't leverage APEX's theme roller or template system, meaning you lose the ability to change the application's look with a few clicks.
APEX way: APEX has a native Map region (since version 21.2) that supports OpenStreetMap, Oracle Spatial, and GeoJSON. You can bind it to a SQL query, and it handles markers, layers, and interactivity declaratively.
Claude's way: Loaded Leaflet.js via CDN and initialized the map manually in JavaScript. This works and is actually more flexible (you can do anything Leaflet supports), but it's reinventing a wheel that APEX already has.
APEX way: Oracle JET charts are built into APEX. You can create bar charts, line charts, pie charts — all backed by SQL queries, with interactive tooltips and responsive sizing.
Claude's way: Used styled HTML divs with color-coded text for positive/negative values. It looks good, but it's static visualization rather than interactive charts. Adding sparklines or trend charts would require a charting library.
The AI chose the approach with the broadest applicability and lowest dependency on platform-specific knowledge. HTML, CSS, JavaScript, and fetch() work everywhere — in APEX, in a plain HTML file, in React, in any web context. APEX-specific components like REST Data Sources, Map regions, and JET Charts are more powerful within APEX but require knowledge that the AI doesn't have in depth.
This is a perfectly rational strategy. When you're uncertain about a platform's specific capabilities, you fall back to fundamentals. And web fundamentals are what Claude knows best.
A few observations on using Claude's Chrome extension for APEX development:
What works well:
What's challenging:
| Scenario | Chrome Extension | OpenClaw Agent |
|---|---|---|
| Quick prototype / POC | ✅ Perfect | Overkill |
| One-off app building | ✅ Great | Unnecessary |
| Recurring / scheduled tasks | ❌ Requires you present | ✅ Runs autonomously |
| Learning APEX | ✅ Watch and learn | Too hands-off |
| Production app maintenance | ❌ Too risky | ⚠️ With guardrails |
| Complex multi-page apps | ⚠️ Context limits | ✅ Better suited |
The Chrome extension is the accessible option. Anyone with a Claude subscription can try it right now. No infrastructure, no configuration, no dedicated hardware. You open your browser and start talking.
The OpenClaw agent is the powerful option. It's for when you want the agent to work independently, on a schedule, with persistent memory and communication channels.
They're not competing approaches. They're different tools for different situations.
I've been building Oracle APEX applications for years. Watching an AI build one in real-time — making mistakes, discovering workarounds, and ultimately delivering a working product — has shifted how I think about the platform.
APEX's strength is also its challenge for AI. The Page Designer is incredibly powerful for human developers. It's visual, it's interactive, and it surfaces properties contextually. But those same qualities make it hard to automate. There's no CLI for APEX development (beyond SQLcl and the PL/SQL API). The Page Designer's internal model (pe) isn't documented for external use. Template IDs vary between workspaces. It's a platform built for human hands.
And Oracle knows this. That's exactly why APEXLang exists.
At APEXWorld 2025, Michael Hichwa (VP of Oracle APEX) demoed APEXLang — a domain-specific language and .apx file format that provides a human-readable, file-based definition of an entire APEX application. Unlike the traditional approach, where application metadata lives exclusively in the Oracle Database, APEXLang uses a formal grammar to define pages, regions, buttons, and everything else as plain text files. It integrates with SQLcl and SQL Developer, supports a compile/uncompile engine to sync files with the database, and — critically — is designed to be AI-friendly. Kris Rice from Oracle described it as "transformative for APEX."
This is the missing piece. Right now, when Claude builds an APEX app through the Chrome extension, it has to navigate a visual UI designed for human interaction, clicking through Page Designer, right-clicking for context menus, and reverse-engineering the pe internal API to set property values. It works, but it's fragile and slow. With APEXLang, an AI wouldn't need to touch the browser at all. It could generate .apx files directly — structured, version-controllable, diffable text — and compile them into a working application. That's not a workaround. That's a native development path.
APEXLang is part of Oracle's broader GenDev (Generative Development) initiative, which is weaving generative AI throughout APEX. APEX already has an AI Assistant that can generate application blueprints from plain English descriptions, write and refine SQL queries, author HTML/CSS/JavaScript/PL/SQL code, and even add conversational AI components to applications. GenDev is about shifting the developer's focus from the "how" to the "what" — describe what you want, and the platform builds it. APEXLang gives that vision a concrete file format that LLMs can produce, review, and iterate on.
Expected to arrive with APEX 25.1, APEXLang also opens the door to proper CI/CD workflows — .apx files in Git, code reviews through pull requests, automated linting, static analysis — things the APEX community has wanted for years. For AI agents specifically, it means the next version of this experiment won't need to navigate a UI at all. It'll generate .apx files, compile them via SQLcl, and the dashboard will just exist. No clicking, no pe hacks, no character limit surprises.
We're not there yet. But what we built today — an AI navigating the browser, reverse-engineering internal APIs, and shipping a working dashboard — is the bridge between where APEX is now and where APEXLang will take it.
The AI's "bad practices" are actually informative. When Claude chose to build an SPA inside a Static Content region instead of using native APEX components, it revealed something about the state of AI and specialized platforms. General-purpose AI models haven't been specifically trained on APEX development patterns. They don't know about REST Data Sources, Template Components, or the Map region. This gap will close over time — especially once APEXLang gives LLMs a structured, text-based format to learn from — but right now, the AI is operating like a talented web developer who's never used APEX before. And that's exactly what it is.
The prototype is the value, not the architecture. If I had asked a junior developer to build this dashboard, I'd review it and refactor. I'd replace the client-side fetches with REST Data Sources, swap the custom CSS for Theme Roller classes, and convert the hardcoded market data to a proper data source. That's a normal workflow. The AI gives you a working starting point in minutes instead of hours. The "proper APEX way" refactoring can come later, and now you have something concrete to refactor rather than a blank page.
It won't be perfect. It won't follow every best practice. But in 30 minutes you'll have a working, live-data dashboard — and a much better understanding of what AI-assisted development actually looks like in practice.
The OpenClaw approach is for builders who want an autonomous teammate. The Chrome extension approach is for everyone else. Anyone who's ever stared at a blank APEX page and thought, "I know what I want, I just don't know how to get there."
Both approaches have the same fundamental insight. AI doesn't need to be an APEX expert to build something useful in APEX. It needs to be a good web developer — and that's exactly what modern language models are.
The gap between "AI that knows web development" and "AI that knows APEX development" is where the interesting work happens. It's where the AI improvises, adapts, and sometimes finds solutions that no human would think of (like reverse-engineering the pe internal API to bypass UI limitations).
That gap is also shrinking. Every time someone builds an APEX app with AI and shares the experience, the training data improves. The next model will know about REST Data Sources. The one after that will know about Template Components. Eventually, the AI won't need to fall back to a Static Content region because it'll know the "APEX way" as well as any senior developer.
But even today, with all its rough edges, an AI that can open your browser and build you a working dashboard from a single sentence is not the future. It's the present. And it's available to anyone with a Chrome extension and a subscription.
The future of development isn't about replacing the developer. It's about removing the gap between having an idea and seeing it run.
This is Part 2 of the "AI Agent Builds Oracle APEX" series. Part 1 covered the OpenClaw autonomous agent approach. Part 3 will explore using Claude to refactor the dashboard into proper APEX native components: REST Data Sources, Map regions, and Template Components.