DEV Community: Sanghun Kang

Multilingual Ghost CMS Blog: 9. Language Switching on Author and Post Pages

Sanghun Kang — Wed, 07 Oct 2026 02:30:37 +0000

There were still two issues left in the existing theme.

On Tag pages, only posts in the selected language are shown, but on Author pages, both English and Korean posts appear together.
Even if a translated post exists, changing the language in the Language selector takes you not to that post, but to the main page of the selected language.

In 0.0.9, I updated the Author page to work the same way as the existing Tag page, and I changed #multi posts so they go directly to the translated post.

This is the /author/sanghun/ screen in theme 0.0.8. The selector is set to English, but English and Korean posts still appear together in one list.

0.0.9 · Author filtering and post language switching

Adding multilingual handling to the Author page

The current Author page uses this single URL.

/author/sanghun/

When Ghost renders this page, it fetches all of the author's posts without separating them by language. Because the language stored in the browser's localStorage cannot be known on the server, the Handlebars template also cannot prefetch English and Korean posts separately.

I solved this issue the same way as the existing Tag page.

On the server, all posts are rendered.
Each post card includes all tags for that post.
In the browser, the currently selected language is checked.
Only cards with matching #en or #ko are shown.

author.hbs

The data-tags attribute of each post card includes both public tags and internal tags.

{{#foreach posts}}
    <div class="post-card" data-tags='[{{#foreach tags visibility="all"}}"{{name}}"{{#unless @last}},{{/unless}}{{/foreach}}]'>
        {{> "post-card"}}
    </div>
{{/foreach}}

The important part here is visibility="all". Since #en, #ko, and #multi are internal tags, they would not be included in the {{#foreach tags}} result without this option.

assets/js/util.js

I extracted the shared logic into filterArchivePostsByLanguage() so the Tag page and Author page can use the same filtering function.

function filterArchivePostsByLanguage() {
  const supportedLanguages = ["en", "ko"];
  const selectedLanguage = getSelectedLanguage();
  const postCards = document.querySelectorAll("div.post-card[data-tags]");
  let visibleCount = 0;

  postCards.forEach((card) => {
    let tagNames = [];

    try {
      tagNames = JSON.parse(card.getAttribute("data-tags") || "[]");
    } catch (error) {
      tagNames = [];
    }

    const cardLanguage = supportedLanguages.find((language) =>
      tagNames.includes(`#${language}`)
    );

    if (cardLanguage !== selectedLanguage) {
      card.style.display = "none";
      return;
    }

    visibleCount += 1;
    setTimeout(() => {
      card.style.opacity = 1;
      card.querySelectorAll(".post-card-excerpt").forEach((excerpt) => {
        excerpt.style.opacity = 1;
      });
    }, 10);
  });

  return visibleCount;
}

In author.hbs and tag.hbs, this function is called after the DOM is ready.

document.addEventListener('DOMContentLoaded', function() {
    filterArchivePostsByLanguage();
});

Now on the Author page as well, if the Language selector is set to English, only #en posts are shown, and if it is set to Korean, only #ko posts are shown.

This is the result of selecting English on the same /author/sanghun/ URL. Only #en posts remain.

If you select Korean without changing the URL, only #ko posts remain.

Moving to the translated post from a `#multi` post

In this blog, posts that are translations of each other follow these rules.

The slug of an English post ends with -en.
The slug of a Korean post ends with -ko.
Both posts have the #multi internal tag.

For example, the following two posts are translations of each other.

/example-post-en/
/ko/example-post-ko/

In 0.0.8, I used these rules to generate the hreflang URL automatically. In 0.0.9, I extended that so the Language selector can also use the URL that was already computed.

partials/hreflang-multi.hbs

I store the current page's content type, whether it is a #multi post, the current language, and the language-specific URLs in a global object.

window.casperMultiLanguageContext = {
    contentType: "{{contentType}}",
    isMulti: isMulti,
    currentLanguage: lang,
    urls: urls
};

If it is a #multi post, urls has the following form.

{
  en: "https://example.com/example-post-en/",
  ko: "https://example.com/ko/example-post-ko/"
}

default.hbs

When the Language selector value changes, it checks whether the current page is a #multi post. If the conditions match, it immediately moves to the post URL for the selected language.

if (
    contentContext &&
    contentContext.contentType === 'post' &&
    contentContext.isMulti &&
    contentContext.urls[selectedLanguage]
) {
    window.location.href = contentContext.urls[selectedLanguage];
} else {
    window.location.href = selectedLanguage === 'ko' ? '/ko/' : '/';
}

The final behavior is as follows.

#multi post: move to the version of that post in the other language
Post without #multi: move to the main page of the selected language
Page: move to the main page of the selected language
Tag or Author page: reload the current URL and show only posts in the selected language
Any other screen: move to the main page of the selected language

On the Korean translated post, the selector points to Korean.

If you switch the selector to English, it goes directly not to the English main page but to the corresponding /orca-codex-threads-chatgpt-en/ post.

Limitations of Author page filtering

Language filtering on the Author page works by hiding cards that have already been rendered in the browser. As a result, the pagination calculated by Ghost is still based on the full set of posts before language filtering.

As the number of posts grows, the following issues may appear.

The number of posts actually visible on a page may decrease.
Some pages may contain very few posts in the selected language.
The total number of pages may not match the number of posts in the selected language.

On the current blog, this causes no practical problem, so I chose the same approach as the existing Tag page. If accurate language-specific pagination becomes necessary later, it can be changed to a method that adds language-specific Channels without modifying Ghost Core.

Proposal for Language-Specific Author Channels

Result

In 0.0.9, the behavior of the Language selector was changed to fit the context of each screen.

On the Author page, you can now view only posts in the selected language just like on the existing Tag page. On translated #multi posts, it goes directly to the corresponding post without passing through the main page.

I did not modify Ghost Core or the database. Since this change was also handled entirely within the theme, it can be applied as-is in managed hosting environments like ghost.io.

This article was originally published on Sanghun Kang’s blog.

How to Make Orca Codex Threads Appear in the ChatGPT App

Sanghun Kang — Wed, 07 Oct 2026 00:00:00 +0000

Orca was getting a lot of attention, so I gave it a try. It turned out to be genuinely useful for managing worktrees and terminal sessions in one place. Then I hit a deal-breaker: Codex threads created in Orca did not appear in the ChatGPT app. The reverse worked fine. Threads created in ChatGPT were visible when I launched Codex from Orca. For someone who wants the same setup everywhere, that asymmetry was a serious problem.

The cause was simple. Orca was using its own CODEX_HOME. Pointing it to the same directory as the ChatGPT app fixed the issue.

The solution is to set CODEX_HOME to ~/.codex for the Codex process that Orca launches.

env CODEX_HOME="$HOME/.codex" codex

There is one catch: putting this in .zshrc does not work.

The Problem

A Codex thread is represented by roughly two kinds of data:

sessions/.../rollout-*.jsonl: the actual conversation and execution events
state_5.sqlite: an index containing the thread ID, title, working directory, timestamps, and JSONL path

The ChatGPT app and a regular Codex CLI session use this directory by default:

~/.codex/
├── sessions/
└── state_5.sqlite

At the time, Orca forced Codex to use a separate managed directory:

~/Library/Application Support/orca/codex-runtime-home/home/
├── sessions/
└── state_5.sqlite

That split the thread storage into two independent paths:

Thread started in the ChatGPT app
└── ~/.codex

Thread started in Orca
└── ~/Library/Application Support/orca/codex-runtime-home/home

The ChatGPT app reads ~/.codex, so it could not display threads that existed only in Orca's managed directory. Orca, however, could import existing sessions from ~/.codex. That one-way import explained the odd behavior: ChatGPT threads were visible in Orca, but Orca threads were missing from ChatGPT.

Root Cause

Reading Orca's source revealed the following launch sequence:

Orca prepares its own managed runtime home.
It starts Codex with CODEX_HOME set to that directory.
It reapplies the managed value after the shell starts.

That is why adding the following line to .zshrc is not enough:

export CODEX_HOME="$HOME/.codex"

The shell may load the value, but Orca overwrites it when launching Codex.

Symlinking only the sessions directory is not a complete fix either. The conversation body lives in JSONL files, but the thread list and metadata also live in state_5.sqlite. If the JSONL files and SQLite index point to different stores, a thread may exist on disk without appearing in the app.

The important part is to make Codex use the same CODEX_HOME as the ChatGPT app from the moment the process starts.

The Fix

Open the following setting in Orca:

Settings > Agents > Codex > Command

Replace the default codex command with:

env CODEX_HOME="$HOME/.codex" codex

Do not add this command to .zshrc. It belongs in Orca's Codex Command field as a command override.

New Codex threads started from Orca will now be written to:

~/.codex/sessions/
~/.codex/state_5.sqlite

Because the ChatGPT app reads the same store, those threads appear in its sidebar as well.

Existing Orca Threads Are Not Migrated Automatically

This setting changes where future threads are stored. Threads created before the change remain in Orca's managed store:

~/Library/Application Support/orca/codex-runtime-home/home/sessions/
~/Library/Application Support/orca/codex-runtime-home/home/state_5.sqlite

To make an existing Orca thread visible in ChatGPT, copy or hard-link its JSONL file into ~/.codex/sessions/, then migrate the matching threads row into ~/.codex/state_5.sqlite. Back up both databases first and move only the required row. Replacing the entire database can wipe out threads that already exist in ChatGPT.

Detours and Dead Ends

Why not just set CODEX_HOME in .zshrc?

My first attempt was:

export CODEX_HOME="$HOME/.codex"

It failed because Orca sets CODEX_HOME to its managed runtime home when Codex launches and reapplies that value after shell startup. Changing only the shell configuration is therefore not reliable.

What does “Codex home to import from” do?

This option does not change the home directory used by the Codex process. It performs a one-way import of existing sessions from ~/.codex/sessions into Orca's managed home.

That behavior explains the asymmetry: threads created in ChatGPT were visible in Orca, while threads created in Orca were invisible in ChatGPT.

This article was originally published on Sanghun Kang’s blog.

Multilingual Ghost CMS Blog: 8. Automating hreflang for #multi Posts

Sanghun Kang — Tue, 06 Oct 2026 02:04:46 +0000

💡 On Managed Ghost hosting, you cannot modify Ghost Core or register custom Handlebars helpers. This is the approach I chose to eliminate repetitive Code Injection within that constraint.

For each post, I could manually insert hreflang into Ghost Admin's Code Injection. But every time I publish a translated post, I would have to enter both the English URL and the Korean URL repeatedly on both posts. There is also a chance of copying a URL incorrectly or adding it to only one side.

In 0.0.8, I changed this so the theme handles the job automatically. I also removed the tag-order dependency issue that surfaced along with it.

This is a screen showing a real published post imported into local Ghost. The slug ends with orca-codex-threads-chatgpt-ko, and the tags include both #ko and #multi.

0.0.8 · Automated bilingual hreflang and tag detection

Rules for multilingual posts

I use the following rules for automation.

The English post slug ends with -en.
The Korean post slug ends with -ko.
Add the #multi internal tag to posts whose translations are all ready.
Each post must have either the #en or #ko internal tag to indicate its own language.

For example, the two posts below are one translation pair.

English slug: multilingual-ghost-cms-en
Korean slug:  multilingual-ghost-cms-ko

The actual URLs are generated like this.

https://sanghunkang.com/multilingual-ghost-cms-en/
https://sanghunkang.com/ko/multilingual-ghost-cms-ko/

partials/hreflang-multi.hbs

I separated the code that generates multilingual URLs for posts and pages into a separate partial.

First, set the supported languages and the default language.

var LANGS = ["en", "ko"];
var DEFAULT_LANG = "en";

Next, turn all of the post's tag names into a JavaScript array.

var tagNames = [
    {{#foreach tags visibility="all"}}
        "{{name}}"{{#unless @last}},{{/unless}}
    {{/foreach}}
];

The reason for specifying visibility="all" is that #multi, #en, and #ko are all internal tags. Without this option, Ghost excludes internal tags from the loop result.

If there is no #multi, do nothing.

if (tagNames.indexOf("#multi") === -1) return;

The current post's language is also found from the tag array.

var lang = null;
LANGS.forEach(function(l) {
    if (tagNames.indexOf("#" + l) !== -1) lang = l;
});

if (!lang) return;

If you remove the trailing -en or -ko from the slug, you get the stem shared by the translated posts.

var suffixPattern = new RegExp("-(" + LANGS.join("|") + ")$");
var stem = slug.replace(suffixPattern, "");

Append each language suffix and URL prefix back onto this stem to build the URL for each language.

function buildUrl(l) {
    var prefix = (l === DEFAULT_LANG) ? "" : "/" + l;
    return siteUrl + prefix + "/" + stem + "-" + l + "/";
}

Finally, add hreflang links to <head>.

var html = "";

LANGS.forEach(function(l) {
    html += '<link rel="alternate" hreflang="' + l + '" href="' + buildUrl(l) + '"/>';
});

html += '<link rel="alternate" hreflang="x-default" href="' + buildUrl(DEFAULT_LANG) + '"/>';

document.head.insertAdjacentHTML("beforeend", html);

Calling the partial in post and page contexts

In the <head> of default.hbs, call the partial when the current view is a post or a page.

{{#is "post"}}
    {{#post}}
        {{> "hreflang-multi"}}
    {{/post}}
{{/is}}

{{#is "page"}}
    {{#page}}
        {{> "hreflang-multi"}}
    {{/page}}
{{/is}}

It must be called inside the {{#post}} and {{#page}} contexts so the partial can use the current content's {{slug}} and {{tags}}.

The problem that depended on tag order

The existing Tag page used the rule that the second tag was the language tag.

data-language="{{tags.[1].name}}"

With this approach, if the tag order changes, language filtering breaks.

[Ghost, #ko, #multi]  -> works
[#multi, Ghost, #ko]  -> fails

In 0.0.8, all tags of each post are placed into data-tags.

<div class="post-card" data-tags='[{{#foreach tags visibility="all"}}"{{name}}"{{#unless @last}},{{/unless}}{{/foreach}}]'>

JavaScript searches the entire array for the language tag.

let cardLang = null;

LANGS.forEach(l => {
    if (tagNames.indexOf('#' + l) !== -1) {
        cardLang = l;
    }
});

Now it does not matter which position #en or #ko is in.

I also did not use Ghost's {{#has tag="..."}} helper to detect internal tags. The display name of the internal tag is #multi, but its actual slug is hash-multi, so if you confuse the name and slug, the condition can fail silently. Passing all internal tag names into an array and comparing them explicitly in JavaScript was more predictable.

Checking the result

Open Developer Tools on a #multi post and run the code below.

[...document.querySelectorAll('link[rel="alternate"][hreflang]')]
  .map(link => [link.hreflang, link.href]);

On both the English post and the Korean post, three links, en, ko, and x-default, should appear, and each URL should point to the correct translated post.

This is the result of inspecting the DOM on the Korean Orca post. en points to the English translated post, ko points to the current Korean post, and x-default points to the English translated post. The black panel is an overlay showing the actual DOM query result on the screen.

On the Tag page, even if you change the order of a post's tags, only posts in the selected language should still display correctly.

Things to watch out for

#multi should be added only when all language versions actually exist. If there is only a Korean post but you add #multi, the theme will also generate an English URL according to the rule, and that URL will return a 404.

Also, the post's hreflang is added to <head> by browser JavaScript. Google renders JavaScript, so it can process this approach, but some crawlers with weak JavaScript rendering may miss the links.

Starting from 0.0.8, if you set the language tag and #multi correctly on translated posts, hreflang is generated automatically.

Syncing Codex Settings and Conversation History Across Multiple Macs

Sanghun Kang — Tue, 06 Oct 2026 00:00:00 +0000

I use Codex on both a MacBook and a Mac Mini. I wanted not only the same skills and settings on both machines, but also the ability to continue a conversation started on either one.

I added Codex's .codex directory to Syncthing using the same approach I had used for syncing Claude Code settings across multiple Macs.

The files synchronized correctly, but sessions created on the other machine still did not appear in the left sidebar.

Syncthing reported that everything was up to date, yet a Codex session created on the Mac Mini was missing from the MacBook sidebar.

Conversation data lives in ~/.codex/sessions/**/*.jsonl.
The sidebar reads each machine's local ~/.codex/state_5.sqlite index.
The JSONL file had arrived, but its session ID was absent from the receiving machine's SQLite database.

This post explains how I synchronize Codex settings and conversation JSONL files in both directions, then automatically repair each machine's local sidebar index as soon as Syncthing finishes receiving a file.

What lives inside ~/.codex

Codex keeps its settings and local task data under ~/.codex/.

Path	Description	Sync
AGENTS.md	Global instructions	Yes
config.toml	Codex configuration	Yes
rules/	Execution rules	Yes
skills/	Custom skills	Yes
automations/	Automation settings	Yes
sessions/	Active task JSONL files	Yes
archived_sessions/	Archived task JSONL files	Yes
history.jsonl	Input history	Yes
session_index.jsonl	Auxiliary session index	Yes
attachments/	Task attachments	Yes
state_5.sqlite*	Machine-specific sidebar and runtime state	No
auth.json and other credentials	Machine-specific authentication	No
Caches, logs, and plugin runtimes	Re-creatable or machine-specific	No

When I synchronized Claude Code settings, I excluded sessions. This time, continuing Codex tasks across machines was the point, so I included both sessions/ and archived_sessions/.

Why not synchronize state_5.sqlite directly?

Synchronizing SQLite would seem to make both sidebars identical automatically. I did not like that approach.

While Codex is running, SQLite may use all three of these files:

state_5.sqlite
state_5.sqlite-wal
state_5.sqlite-shm

Syncthing does not transfer these three files as one atomic unit.
Both machines may modify the database at the same time.

That can create conflict files or cause one machine's changes to overwrite the other's.

The safer design is to synchronize only the JSONL source records and let each machine rebuild its own SQLite index.

The actual problem

A Codex session created on the Mac Mini had already synchronized its JSONL record to the MacBook, but the session did not appear in the MacBook sidebar.

The JSONL file on the MacBook was byte-for-byte identical to the one on the Mini, and .stignore was not excluding it. The ID existed in the Mini's state_5.sqlite, but not in the MacBook's database.

Syncthing had finished its job. Codex simply had not registered the newly received JSONL file in the local sidebar index.

Running codex resume [SESSION_ID] could reopen the session. But finding an ID and manually resuming it every time is not synchronization. It is manual recovery, which was not what I wanted.

Syncthing setup

1. Install Syncthing

Install and run Syncthing on both machines with Homebrew.

brew install syncthing
brew services start syncthing

The web UI is available at http://localhost:8384 by default.

2. Connect the two machines

Copy the Device ID from one machine and add it as a Remote Device on the other. Approve the connection request to begin bidirectional synchronization.

3. Register ~/.codex as a shared folder

Use the same Folder ID on both machines.

Folder Label: codex-config
Folder ID: codex-config
Folder Path: /Users/<username>/.codex
Folder Type: Send & Receive

4. Use an allowlist-style .stignore

The .codex directory mixes portable configuration with credentials and machine-specific runtime state. An allowlist is safer than continually expanding an exclusion list.

// Codex history + portable setup
!/config.toml
!/AGENTS.md
!/rules
!/rules/**
!/skills
!/skills/**
!/automations
!/automations/**
!/sessions
!/sessions/**
!/archived_sessions
!/archived_sessions/**
!/history.jsonl
!/session_index.jsonl
!/attachments
!/attachments/**

// Ignore everything else
*

Following a suggestion from Sean Dotson, I added / to anchor the allowlist patterns at the folder root. This includes only the intended top-level files and folders and reduces unnecessary traversal of subdirectories.

With this setup, state_5.sqlite, its WAL and SHM files, credentials, caches, and logs are excluded by the final *.

Repairing a missing sidebar entry after JSONL arrives

Codex App Server's thread/list method supports the useStateDbOnly option.

true: return only tasks already registered in SQLite.
false: scan JSONL task logs and repair missing metadata.

There is no need to modify SQLite directly. Ask Codex itself to scan the JSONL files again.

The essential request looks like this:

{
  "method": "thread/list",
  "id": 1,
  "params": {
    "limit": 100,
    "archived": false,
    "sourceKinds": ["cli", "vscode", "appServer"],
    "useStateDbOnly": false
  }
}

Paginating through both active and archived tasks registers JSONL-only tasks in the local state database. The operation is safe to repeat and never writes to SQLite directly.

Choosing the right trigger

The trigger required more thought than the repair script itself.

First attempt: a five-minute LaunchAgent

My first version ran once at login, watched session_index.jsonl, and rescanned every five minutes in case it missed an event.

It was reliable, but imprecise. A file could arrive and still wait until the next interval, while a full scan ran even when nothing had changed.

More importantly, I disliked wasting resources for no reason.

Second attempt: Codex SessionStart and SessionEnd

Codex can run hooks at session start and end. These hooks still did not match the event I needed.

The relevant event is not "a Codex session started." It is "Syncthing finished receiving a remote JSONL file." Starting or closing the app does not correspond to file arrival.

An app launch or shutdown hook would have made the solution much simpler, but Codex does not currently provide one.

Final approach: Syncthing ItemFinished events

Syncthing provides a REST Event API. ItemFinished is emitted after a newer file version finishes synchronizing.

GET /rest/events?events=ItemFinished

A listener on each machine long-polls this endpoint and handles only events matching all four conditions:

The Folder ID is codex-config.
error is empty.
The event is an update to file contents.
The path matches sessions/**/*.jsonl or archived_sessions/**/*.jsonl.

Several files may arrive in quick succession, so the listener briefly debounces them and runs one repair. It also performs a complete repair when it starts, covering events missed while the listener was offline. A file lock prevents automatic and manual reconciliation from overlapping.

The final flow is:

Create a task on the Mini
  → Syncthing sends the JSONL file to the MacBook
  → The MacBook ItemFinished listener receives the event
  → MacBook Codex App Server scans the JSONL histories
  → The MacBook repairs its local SQLite index
  → Reopen Codex to show the task in the MacBook sidebar

Tasks created on the MacBook follow the same flow in reverse

Limitation: the running app's UI cache

Even after this automation, an already-running Codex app does not refresh its sidebar immediately. JSONL synchronization and local SQLite index repair finish automatically, but the task list already held in memory does not appear to learn that an external process updated the index.

I could not find an official command or supported interface for forcing a sidebar refresh. To see a newly synchronized task in the sidebar, I currently need to close and reopen Codex.

It is not fully real-time synchronization, but it is good enough for how I work. Reopening Codex after working on the other machine shows the latest sessions, and I am happy with that result.

LaunchAgent configuration

Syncthing itself already runs as a Homebrew LaunchAgent on both machines. I installed the event listener as a separate LaunchAgent instead of modifying Homebrew's service file. This survives brew upgrade and makes it possible to restart and inspect Syncthing and the listener independently.

Bidirectional task synchronization requires installing this LaunchAgent on both Macs because each receiving machine must register incoming JSONL files in its own local index.

The complete implementation is available in the public reconcile-codex-threads repository. Automatic repair uses these three files:

codex_thread_sync_listener.py: waits for Syncthing ItemFinished events.
codex_thread_index_reconciler.py: repairs the local index through Codex App Server.
install_launch_agent.py: installs a LaunchAgent using the current user's paths.

The essential LaunchAgent configuration is:

<key>Label</key>
<string>local.reconcile-codex-threads.listener</string>

<key>ProgramArguments</key>
<array>
    <string>/usr/bin/python3</string>
    <string>/Users/&lt;username&gt;/.local/libexec/codex_thread_sync_listener.py</string>
    <string>--syncthing-config</string>
    <string>/Users/&lt;username&gt;/Library/Application Support/Syncthing/config.xml</string>
    <string>--reconciler</string>
    <string>/Users/&lt;username&gt;/.local/libexec/codex_thread_index_reconciler.py</string>
</array>

<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>

The listener waits for Syncthing events and runs only when a relevant JSONL file arrives. It reads the API key from each machine's Syncthing config.xml at runtime.

Manual reconciliation skill

I also created $reconcile-codex-threads as a manual inspection path. It performs the following steps:

Request an immediate rescan of the codex-config folder on both machines.
Reconcile both local indexes from JSONL histories.
Retrieve both state-only sidebar inventories through App Server.
Compare task IDs and archive state.
Report titles and IDs that exist on only one machine.

The controller can also be run directly:

/usr/bin/python3 \
  "${CODEX_HOME:-$HOME/.codex}/skills/reconcile-codex-threads/scripts/reconcile_codex_threads.py"

The exact filename is reconcile_codex_threads.py. It does not transfer files itself. It requests a Syncthing rescan, repairs both local indexes, and compares the results.

On the machine used to run the controller, create the non-synchronized local configuration file ~/.config/reconcile-codex-threads/config.json and specify the other Mac's SSH alias.

{
  "ssh_host": "other-mac"
}

A converged result looks like this:

{
  "status": "converged",
  "local": {
    "thread_count": 277,
    "active_count": 268,
    "archived_count": 9
  },
  "remote": {
    "thread_count": 277,
    "active_count": 268,
    "archived_count": 9
  },
  "only_local": [],
  "only_remote": [],
  "archive_state_mismatches": []
}

Here, converged means both task inventories and archive states match. Project and section organization, pins, display order, icons, and colors are not synchronized. These could be implemented separately, but I left them out because my goal was to continue the same conversations on another Mac. You may need to reopen Codex for new tasks to appear in the running app.

Lessons learned

JSONL and the sidebar are different states

A file existing on disk does not guarantee that it will appear in the sidebar. The conversation record and the local display index must be diagnosed separately.

Run one complete repair when the listener starts

Syncthing's Event API is not an infinite permanent event log. The listener may miss events while it is stopped, so it should scan all JSONL histories once at startup.

Active tasks change frequently

The same JSONL file can arrive repeatedly while a conversation is active. Running a complete repair on every event would be wasteful, so a short debounce and a single-execution lock are important.

References

-update- 2026-10-09: Thread registration stopped after an app update

The setup eventually stopped working again. Syncthing reported that synchronization was complete, but recent conversations from the other Mac were missing from the Codex task list.

The JSONL files had reached both machines, and both Syncthing and the event listener were running. The failure was in the executable used for index repair. The LaunchAgent still passed this fixed path through --codex-bin, but the currently installed app no longer contained that file:

/Applications/ChatGPT.app/Contents/Resources/codex

File arrival events were being received normally. Each repair then failed with No such file or directory. The executable in the current app installation was at:

/Applications/ChatGPT.app/Contents/Resources/codex-cli/bin/codex

Use the current executable and discover it at runtime

I first ran the existing reconciler with the new executable. The thread/list request with useStateDbOnly: false still worked and registered recent Mini conversations that were missing locally. I connected to the Mini over SSH and verified repair in the other direction as well.

I then changed how the scripts select the executable:

The reconciler checks the current app's codex-cli/bin/codex layout first. Older app layouts, the managed App Server's ~/.codex/packages/app-server-daemon/current/bin/codex, and a CLI on PATH are fallback candidates.
I removed the obsolete --codex-bin argument pair from the LaunchAgent.
The listener no longer fixes the executable path at startup. Unless an explicit override is supplied, each repair invocation lets the reconciler discover an available executable again.
The installer no longer writes a resolved executable path into the LaunchAgent by default. Explicit --codex-bin and CODEX_BIN overrides remain available.

I applied the updated listener, reconciler, and LaunchAgent on both Macs and restarted the services. The trigger remains Syncthing's ItemFinished event. The repair still uses Codex App Server rather than editing or synchronizing SQLite directly.

Recovery and verification

With the updated scripts installed, a one-time repair no longer needs an explicit executable path:

/usr/bin/python3 "$HOME/.local/libexec/codex_thread_sync_listener.py" --once

This command assumes the new discovery logic is installed. To test an older copy of the script first, pass the current app path shown above through --codex-bin and check whether the repair API succeeds.

At verification time, all 12 of the Mini's newest threads were registered in the local index. A conversation running locally was also registered on the Mini, and the local desktop task list returned the imported Mini conversations. After restarting the services, both machines logged automatic repairs triggered by received JSONL files with status: ok.

The complete historical inventories still differed. There were 14 older archived entries with listing differences and one archive-state mismatch. Their JSONL files existed on both machines, with old index paths or states still differing. This repair restored recent-thread registration and automatic reconciliation; it did not establish complete historical convergence.

If the running app still holds a cached task list after index repair, closing and reopening Codex may be necessary. If the symptom returns, check the listener logs and the actual Codex executable path as well as Syncthing's status.

This article was originally published on Sanghun Kang’s blog.

Multilingual Ghost CMS Blog: 7. Adding hreflang

Sanghun Kang — Mon, 05 Oct 2026 02:03:59 +0000

The English home is served at /, and the Korean home at /ko/, but search engines had no information indicating that the two pages were versions in different languages.

Providing users with a Language selector and explaining multilingual relationships to search engines are separate issues. For search engines, you need to use hreflang to indicate the relationship between each language URL.

In 0.0.7, I added hreflang to the English and Korean home pages.

0.0.7 · Rename theme folder

0.0.7~0.0.8 · Home and post hreflang

The hreflang needed for the home page

The home URLs for this blog are as follows.

English: https://sanghunkang.com/
Korean:  https://sanghunkang.com/ko/

I wanted to put the following three links in the <head> of both pages.

<link rel="alternate" hreflang="en" href="https://sanghunkang.com/" />
<link rel="alternate" hreflang="ko" href="https://sanghunkang.com/ko/" />
<link rel="alternate" hreflang="x-default" href="https://sanghunkang.com/" />

en and ko point to the home page for each language. x-default is the default page to use when the user's language does not clearly match either one. Since this blog uses English as the default language, I set it to /.

Why `{{#is "home"}}` did not solve it

At first, I tried to check whether the current page was the home page in default.hbs and then output hreflang.

{{#is "home"}}
    ...
{{/is}}

However, in Ghost, {{#is "home"}} is true only at the site root, /. Since /ko/ is the first page of a Collection created with routes.yaml, Ghost does not treat it as the site home.

As a result, hreflang appeared on the English home, but not on the Korean home.

Handling it with contentFor

I changed it so that index-en.hbs and index-ko.hbs, which are used by each language home, pass the same hreflang block, and default.hbs outputs it in <head>.

index-en.hbs

{{!< index}}
{{#contentFor "lang"}}en{{/contentFor}}
{{#contentFor "hreflang-home"}}
    <link rel="alternate" hreflang="en" href="{{@site.url}}/" />
    <link rel="alternate" hreflang="ko" href="{{@site.url}}/ko/" />
    <link rel="alternate" hreflang="x-default" href="{{@site.url}}/" />
{{/contentFor}}

index-ko.hbs

{{!< index}}
{{#contentFor "lang"}}ko{{/contentFor}}
{{#contentFor "hreflang-home"}}
    <link rel="alternate" hreflang="en" href="{{@site.url}}/" />
    <link rel="alternate" hreflang="ko" href="{{@site.url}}/ko/" />
    <link rel="alternate" hreflang="x-default" href="{{@site.url}}/" />
{{/contentFor}}

Both templates pass the same set of URLs. Since hreflang on multilingual pages must reference each other, both the English page and the Korean page should have the same list of language URLs.

default.hbs

Output the passed block before {{ghost_head}}.

{{{block "hreflang-home"}}}

{{ghost_head}}

This approach works regardless of whether Ghost treats /ko/ as the site home. If the page uses index-ko.hbs, the hreflang-home block is passed.

Checking the result

Open the developer tools on the English and Korean home pages respectively, and run the code below.

[...document.querySelectorAll('link[rel="alternate"][hreflang]')]
  .map(link => [link.hreflang, link.href]);

On both pages, all three entries should appear: en, ko, and x-default.

On the English home /, the three links en, ko, and x-default were generated.

[App] Multiple Codex (ChatGPT) accounts on one machine

Sanghun Kang — Mon, 05 Oct 2026 00:00:00 +0000

Fast track: throw this post's URL at your AI and tell it to set this up for you. (The app version is trickier because of signing, so double-check the result.)

TLDR:

Run two (or more) ChatGPT desktop apps, one per account. At the same time.
Updates follow automatically, when you open the app.
Caveat: passkey login won't work. Log in with OTP, password, or SSO.

How

Save this as ~/.local/bin/chatgpt2-rebuild. (You need the original ChatGPT.app installed, and clang to compile the stub → xcode-select --install.) The launcher synchronizes the sidebar state in both directions. It copies ChatGPT's state to ChatGPT2 before launch, then copies ChatGPT2's final state back to ChatGPT after ChatGPT2 exits.

#!/usr/bin/env bash
set -euo pipefail

SRC="/Applications/ChatGPT.app"
DST="/Applications/ChatGPT2.app"
NEW_ID="com.openai.codex2"
NEW_NAME="ChatGPT2"
CODEX_HOME2="$HOME/.codex2"
USERDATA2="$HOME/Library/Application Support/Codex2"
P=/usr/libexec/PlistBuddy

[ -d "$SRC" ] || { echo "ERROR: $SRC not found"; exit 1; }
command -v clang >/dev/null || { echo "ERROR: clang needed (xcode-select --install)"; exit 1; }

# don't clobber a running instance
if pgrep -f "ChatGPT2.app/Contents/MacOS/ChatGPT.bin" >/dev/null; then
  echo "ChatGPT2 is running — quit it first, then re-run."; exit 1
fi

EXE="$($P -c "Print :CFBundleExecutable" "$SRC/Contents/Info.plist")"

echo "[1/5] APFS clone of $SRC → $DST …"
rm -rf "$DST"
cp -Rc "$SRC" "$DST"                      # clonefile: copy-on-write, ~0 extra disk

echo "[2/5] patch Info.plist…"
PL="$DST/Contents/Info.plist"
$P -c "Set :CFBundleIdentifier $NEW_ID" "$PL"
$P -c "Set :CFBundleName $NEW_NAME" "$PL" 2>/dev/null || $P -c "Add :CFBundleName string $NEW_NAME" "$PL"
$P -c "Set :CFBundleDisplayName $NEW_NAME" "$PL" 2>/dev/null || $P -c "Add :CFBundleDisplayName string $NEW_NAME" "$PL"
$P -c "Add :LSEnvironment:CODEX_HOME string $CODEX_HOME2" "$PL" 2>/dev/null || $P -c "Set :LSEnvironment:CODEX_HOME $CODEX_HOME2" "$PL"
$P -c "Add :SUEnableAutomaticChecks bool false" "$PL" 2>/dev/null || $P -c "Set :SUEnableAutomaticChecks false" "$PL"

echo "[3/5] install lazy launcher (update-on-use script + tiny Mach-O stub; main exe → *.bin)…"
mv "$DST/Contents/MacOS/$EXE" "$DST/Contents/MacOS/$EXE.bin"

# (a) launch script — on every open: compare versions, re-clone + reopen if they differ
cat > "$DST/Contents/Resources/cg2-launch.sh" <<'LAUNCH'
#!/bin/bash
set -u
SDIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"   # …/ChatGPT2.app/Contents/Resources
APP="$(cd "$SDIR/../.." && pwd)"                        # …/ChatGPT2.app
BIN="$SDIR/../MacOS/ChatGPT.bin"
SRC="/Applications/ChatGPT.app"
P=/usr/libexec/PlistBuddy
ver(){ "$P" -c "Print :CFBundleShortVersionString" "$1/Contents/Info.plist" 2>/dev/null; }
cur="$(ver "$SRC")"; mine="$(ver "$APP")"
if [ -n "$cur" ] && [ -n "$mine" ] && [ "$cur" != "$mine" ]; then
  # original updated → re-clone in a detached helper, then reopen (this launch is handed off)
  /usr/bin/nohup /bin/bash -c '
    "$HOME/.local/bin/chatgpt2-rebuild" >/tmp/chatgpt2-autoupdate.log 2>&1 \
      && /usr/bin/env -u CODEX_HOME -u ORCA_CODEX_HOME open -a /Applications/ChatGPT2.app
  ' >/dev/null 2>&1 &
  exit 0
fi
# up-to-date → normal launch of account-2 instance
export CODEX_HOME="$HOME/.codex2"

PRIMARY_STATE="$HOME/.codex/.codex-global-state.json"
SECONDARY_STATE="$HOME/.codex2/.codex-global-state.json"

sync_state() {
  local from="$1"
  local to="$2"
  local tmp="${to}.sync.$$"

  [ -f "$from" ] || return 0

  if /bin/cp -p "$from" "$tmp"; then
    /bin/mv -f "$tmp" "$to"
  else
    /bin/rm -f "$tmp"
    return 1
  fi
}

# Keep the sidebar up to date: ChatGPT → ChatGPT2 before launch.
sync_state "$PRIMARY_STATE" "$SECONDARY_STATE" || \
  echo "WARNING: could not import ChatGPT sidebar state" >&2

# Keep the sidebar up to date: ChatGPT2 → ChatGPT after normal exit.
trap 'sync_state "$SECONDARY_STATE" "$PRIMARY_STATE" || true' EXIT

"$BIN" "--user-data-dir=$HOME/Library/Application Support/Codex2" "$@"
status=$?
exit "$status"
LAUNCH
chmod +x "$DST/Contents/Resources/cg2-launch.sh"

# (b) Mach-O stub — launchd won't run a script as a bundle's main executable (POSIX 162),
#     so this tiny stub just hands off to the script above.
SRC_C="$(mktemp /tmp/cg2launcher.XXXX.c)"
cat > "$SRC_C" <<EOF
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <limits.h>
#include <libgen.h>
#include <unistd.h>
#include <mach-o/dyld.h>
int main(int argc, char **argv){
    char exe[PATH_MAX]; uint32_t sz=sizeof(exe);
    if(_NSGetExecutablePath(exe,&sz)!=0) return 71;
    char dir[PATH_MAX]; strncpy(dir,dirname(exe),sizeof(dir));
    char sh[PATH_MAX];
    snprintf(sh,sizeof(sh),"%s/../Resources/cg2-launch.sh",dir);
    char **n=calloc(argc+3,sizeof(char*)); int k=0;
    n[k++]="/bin/bash"; n[k++]=sh;
    for(int i=1;i<argc;i++) n[k++]=argv[i];
    n[k]=NULL;
    execv("/bin/bash",n); perror("execv"); return 72;
}
EOF
clang -O2 -arch arm64 -o "$DST/Contents/MacOS/$EXE" "$SRC_C"; rm -f "$SRC_C"

echo "[4/5] sign — DEEP ad-hoc reseal of the whole clone…"
codesign --force --deep --sign - "$DST"

echo "[5/5] clear quarantine + register…"
xattr -dr com.apple.quarantine "$DST" 2>/dev/null || true
mkdir -p "$USERDATA2"
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f "$DST"

echo "Done (APFS clone)."

This assumes that the two apps are used one at a time. A normal quit is required for the final ChatGPT2 → ChatGPT sync. A force-quit, crash, or sudden shutdown may skip that final copy.

Then run it:

pkill -f "ChatGPT2.app" 2>/dev/null   # quit it if running
chatgpt2-rebuild                       # ~7s, creates /Applications/ChatGPT2.app
env -u CODEX_HOME -u ORCA_CODEX_HOME open -a /Applications/ChatGPT2.app

On first launch, log in to account 2. (Use OTP/password/SSO, not passkey — see the caveat below.)

Note: if you open from a shell that exports CODEX_HOME (e.g. Orca), that value leaks into the app and crosses up your accounts. Open with env -u as shown above.

Why it works

The app's "identity" is its bundle id + signature. After cloning, we change the id to com.openai.codex2, and the launcher injects CODEX_HOME=~/.codex2 + --user-data-dir=…/Codex2. That splits the account (auth.json), the web login, and the Electron single-instance lock, so both run at the same time. (--user-data-dir is the key: Electron's lock is keyed by the user-data-dir, not the bundle id, so changing the id alone won't let two run.)

Why clone, not symlink? If you symlink the frameworks/binary back to the original, the Chromium helper (Codex (Service)) crashes the instant it starts, because its sandbox / framework path resolution needs the real bundle path and a symlink throws it off. The main process then retries the helper forever, pinned at 100% CPU. So "symlink to auto-follow updates" is impossible.

Why --deep re-sign? The inner frameworks/helpers carry OpenAI's team signature (hardened runtime). If only the top bundle is ad-hoc, the team mismatch makes AMFI reject the launch outright (-420). So the whole clone must be re-signed ad-hoc to unify the identity, and then the helper starts. Since the clone is an independent copy, --deep never touches the original. (Conversely, never --deep-sign while the frameworks are symlinks — it would re-sign the original through the links.)

Updates: automatic, on open

The clone is a snapshot from copy time, so it doesn't auto-update on its own. Instead, when you open the app, the launcher compares its version to the original and, if they differ, re-clones automatically (~7s) and relaunches. The original updates as usual via Sparkle, and ChatGPT2 rides on top when you open it. No background daemon, no polling. (Letting ChatGPT2 self-update via Sparkle would be rejected for a signature mismatch, or would wipe the customization, so its self-update is disabled.)

If you run the updater in ChatGPT2, the update fails with a signature mismatch, as shown in the screenshot below.

The signature error shown when attempting to update ChatGPT2

When the original app is updated, ChatGPT2 is updated automatically as well, so there is no need to try to update the copied app.

Caveat: passkey doesn't work

The moment you re-sign, the app loses its Team ID and keychain access. Passkeys live in the iCloud Keychain / Secure Enclave, and access is gated by exactly that, so in ChatGPT2 the "Verify your identity → passkey" screen spins forever. It can't be fixed (that would need OpenAI's real signing certificate, which we don't have). Use "Try another method" with OTP, password, or Google/Apple/MS SSO instead. The session is stored as a cookie, so it persists across restarts.

Part 1 (CLI) is here: Multiple Codex (ChatGPT) accounts on one machine

This article was originally published on Sanghun Kang’s blog.

Multilingual Ghost CMS Blog: 6. Fixing Invisible Post Excerpts on Tag Pages

Sanghun Kang — Sun, 04 Oct 2026 17:59:50 +0000

In the previous version, I also applied multilingual filtering to the Tag page. It shows only the post cards that match the language selected in the Language selector, and I also added an opacity transition so the cards fade in smoothly.

But when I actually used it, there was a problem: the post card titles and images were visible, but the post excerpts remained transparent.

The card title and image are visible, but the excerpt does not appear.

0.0.6 · Fix Tag page excerpt fade-in

Cause

On the Tag page, all post cards are initially made transparent.

.post-card-excerpt,
div.post-card {
    opacity: 0;
    transition: opacity 0.5s ease;
}

Then only the cards that match the selected language are changed to opacity: 1.

setTimeout(() => {
    card.style.opacity = 1;
}, 10);

The issue is that .post-card-excerpt also has opacity: 0 applied separately. Even if the parent card is changed to be visible, the child .post-card-excerpt still has an opacity of 0.

In other words, both the entire card and the excerpt were made transparent, but only the card was made visible again.

Updating tag.hbs

When displaying a card, also find the .post-card-excerpt inside that card and change it to opacity: 1 as well.

setTimeout(() => {
    card.style.opacity = 1;

    const excerpts = card.querySelectorAll('.post-card-excerpt');
    excerpts.forEach(excerpt => {
        excerpt.style.opacity = 1;
    });
}, 10);

card.style.opacity = 1: Shows the entire card.
excerpt.style.opacity = 1: Shows the post excerpt inside the card.
Handle both inside the same setTimeout so the card and excerpt appear together.

Result

Now, when I change the Language selector on the Tag page, the post cards and excerpts for the selected language appear together.

I applied theme version 0.0.6 while keeping the same content and language. When the cards appear, the excerpt opacity is restored as well, so both the title and the post summary are visible.

This was not a problem with the multilingual handling itself. It was a small UI bug caused by applying opacity separately to the parent and child in CSS, while restoring only the parent in JavaScript.

[CLI] Multiple Codex (ChatGPT) accounts on one machine

Sanghun Kang — Sun, 04 Oct 2026 00:00:00 +0000

Ran out of usage, logged out, logged into the other account, got tired of it, so I automated it.

Fast track: throw this post's URL at your AI and tell it to set this up for you.

TLDR:

Make several codex CLIs (two, in this post).
Share everything. Chat history, memory, skills, all of it stays as one. (It literally is one, thanks to symlinks.)
Only the login differs.
This way you can use two or more accounts. For simultaneous use, see the database-locking caveat below.
CLI only. Running two or more desktop apps is covered in the next post.
The same approach works for Claude Code too, not just Codex.

How

Call the existing command codex, and the new one codex2.

1) alias

# ~/.zshrc
alias codex2='CODEX_HOME="$HOME/.codex2" codex'

The first time you run codex2 and log in, ~/.codex2/auth.json is created and you're good to go.

The catch: now codex and codex2 keep separate chat history, memory, skills, and so on.

2) symlink setup

Make ~/.codex2 a selective mirror of ~/.codex. Keep only the account file (auth.json) and the volatile runtime files separate; symlink everything else so it's shared. Save this as ~/.local/bin/codex2-sync:

#!/usr/bin/env bash
set -euo pipefail
SRC="$HOME/.codex"; DST="$HOME/.codex2"

# Kept separate (not shared): the account + volatile runtime
EXCLUDE=(auth.json ipc tmp .tmp cache log mcp-oauth-locks
         process_manager node_repl shell_snapshots computer-use
         .DS_Store .stfolder .stignore)
excluded(){ local n="$1"; for e in "${EXCLUDE[@]}"; do [[ "$n" == "$e" ]] && return 0; done; return 1; }

mkdir -p "$DST"
for path in "$SRC"/* "$SRC"/.*; do
  name="$(basename "$path")"
  [[ "$name" == "." || "$name" == ".." ]] && continue
  [[ -e "$path" ]] || continue
  excluded "$name" && continue
  target="$DST/$name"
  if [[ -L "$target" ]]; then
    [[ "$(readlink "$target")" == "$path" ]] || { rm -f "$target"; ln -s "$path" "$target"; }
  elif [[ ! -e "$target" ]]; then
    ln -s "$path" "$target"
  fi
done
# Prune dangling links whose source is gone
for link in "$DST"/* "$DST"/.*; do
  [[ -L "$link" && ! -e "$link" ]] && rm -f "$link"
done
echo "Synced $DST"

chmod +x ~/.local/bin/codex2-sync && codex2-sync

Now you can run codex (the original) and codex2 (the new one) as separate commands. The limitations of simultaneous use are explained below.

Why it works

All of codex's state lives under CODEX_HOME (default ~/.codex), and the "account" is really just auth.json. So splitting auth.json alone gives you a separate account.

Both accounts use the same SQLite databases to share conversation history. WAL supports concurrent access, but Codex's lock handling can cause startup failures or temporary stalls when multiple instances run at the same time.

I switch to the other account when one account runs out of usage. I do not run both instances at the same time, and I have not encountered these issues in my day-to-day use.

Caveat: the desktop app is a different story

That's all it takes for the CLI. The ChatGPT desktop app, though, is a bit more involved. Next post.

This article was originally published on Sanghun Kang’s blog.

Multilingual Ghost CMS Blog: 5. Making Home Links Language Aware

Sanghun Kang — Sat, 03 Oct 2026 02:02:55 +0000

This explains how to make the home links in the navigation bar, footer, and error page point to the correct language-specific homepage.

Home link in the navigation bar

Home link in the footer

Home link on the error page

There are home links in the navigation bar, footer, and error page. These links are set to @site.url, and regardless of the multilingual settings, they only point to the main page of the default language. Let's modify them so they point to the currently active language instead.

default.hbs

<a class="gh-head-logo{{#unless @site.logo}} no-image{{/unless}}" href="{{#if (block "lang")}}{{@site.url}}/{{block "lang"}}{{else}}{{@site.url}}{{/if}}">

In default.hbs, it works properly if you handle it by using the block "lang" in an if condition, the same way as before.

However, this approach does not work properly on the error page or tag page. That is because these pages do not include index-ko or index-en, and they also do not explicitly assign "lang" values like post or page do. So I decided not to rely on lang.

The new idea is to change the approach so that, as in tag.hbs, it retrieves the selectedLanguage value stored in localStorage and updates the URL based on that value.

Since this needs to be done in default, tag, and error as well, I wanted to create a separate file and reuse it. I made separate functions for these two tasks and stored them in a separate util.js file so they could be reused across multiple files.

function getSelectedLanguage() {
  return localStorage.getItem("selectedLanguage") || "en";
}

function updateLink(selector, language) {
  const element = document.querySelector(selector);
  if (element) {
    let siteUrl = element.getAttribute("href");
    if (!siteUrl.endsWith("/")) {
      siteUrl += "/";
    }
    element.setAttribute("href", `${siteUrl}${language}/`);
  }
}

assets/js/util.js

Using these functions, let's update all files that contain @site.url links.

You can load the newly created js file using the {{asset}} helper.

<script type="text/javascript" src="{{asset 'js/util.js'}}"></script>

Reference:

Ghost Handlebars Theme Helpers: asset

Full code

You can check the full code here on GitHub.

0.0.5 · sanghunka/ghost-multilingual-theme@59b6cc1

error-404.hbs

Let's add this code at the very bottom.

It's simple. It gets selectedLanguage and changes the href of .error-link to match it.

<script type="text/javascript" src="{{asset 'js/util.js'}}"></script>
<script>
document.addEventListener('DOMContentLoaded', function() {
    const selectedLanguage = getSelectedLanguage();
    if (selectedLanguage !== 'en') {
        updateLink('.error-link', selectedLanguage);
    }
});
</script>

Try entering any URL (e.g. {host}/ko/404error) and check whether the home link correctly points to {host}/ko/.

error.hbs

<script type="text/javascript" src="{{asset 'js/util.js'}}"></script>
<script>
document.addEventListener('DOMContentLoaded', function() {
    const selectedLanguage = getSelectedLanguage();
    if (selectedLanguage !== 'en') {
        updateLink('.error-link', selectedLanguage);
        updateLink('.site-nav-logo', selectedLanguage);
    }
});
</script>

tag.hbs

I replaced this code, which I had implemented before,

const selectedLanguage = localStorage.getItem('selectedLanguage') || 'en';

with the newly created function.

<script type="text/javascript" src="{{asset 'js/util.js'}}"></script>

const selectedLanguage = getSelectedLanguage();

default.hbs

<script type="text/javascript" src="{{asset 'js/util.js'}}"></script>
<script>
function initializeLanguageSelector() {
    var selector = document.getElementById('languageSelector');
    var currentUrl = window.location.href;

    if (!currentUrl.includes('/tag/')) {
        var urlLanguage = currentUrl.includes('/ko/') ? 'ko' : 'en';
        localStorage.setItem('selectedLanguage', urlLanguage);
        selector.value = urlLanguage;
    } else {
        selector.value = localStorage.getItem('selectedLanguage') || 'en';
    }

    selector.style.display = 'block';

    selector.addEventListener('change', function() {
        localStorage.setItem('selectedLanguage', this.value);
        if (!currentUrl.includes('/tag/')) {
            window.location.href = this.value === 'ko' ? '/ko/' : '/';
        }
        else {
            window.location = window.location.href;
        }
    });
}

document.addEventListener('DOMContentLoaded', function() {
    initializeLanguageSelector();

    const selectedLanguage = getSelectedLanguage();
    if (selectedLanguage !== 'en') {
        updateLink('.gh-head-logo', selectedLanguage);
        updateLink('section.copyright a', selectedLanguage);
        updateLink('li.nav-home a', selectedLanguage);
    }
});
</script>

Wrapping up

With this approach, it would even be possible to completely replace the block "lang" approach. Even so, I decided to keep the block "lang" approach as is, because from an SEO perspective it has the advantage that the html lang attribute is rendered server-side, and because I do not think this part is all that important.

Hostname Is Not a Device Identifier

Sanghun Kang — Sat, 03 Oct 2026 00:00:00 +0000

Did I really use that many tokens?

I was looking at the Claude Code status line as usual when one number looked wrong.

Last 30 Days            $4038.03 · 5.1B tokens

Two days earlier it had been 2.5B. There was no way I had used another 3B tokens in between. If the number had doubled, something was being counted twice.

The aggregation setup

My ~/.claude directory is synced between a MacBook and a Mac mini through Syncthing. The token usage summary sits on top of that with a simple structure. Each machine writes only to a JSON file named after its own hostname, and the status line sums every JSON file in the directory with a *.json glob.

USAGE_DIR="$HOME/.claude/usage-summary"
HOSTNAME_SHORT="$(hostname -s | tr -d '\n\r' | tr -c 'a-zA-Z0-9.-' '_')"
CACHE_FILE="$USAGE_DIR/$HOSTNAME_SHORT.json"

Each machine owns its own file. Aggregation happens at the directory level. It seemed simple enough.

Then I opened the directory.

Mac.json
mini.json
Sanghuns-MacbookPro-M4Max.json

Three files. But there were only two machines.

Catching the duplicate with data

The first question was, "Are two of these files coming from the same machine?" ccusage reads the local ~/.claude/projects/**/*.jsonl session logs on the machine where it runs, so if two files came from the same machine, they could only be two snapshots of the same history at different points in time.

There were two checks.

First, the scale of the 30-day totals.

File	last30 tokens
`Mac.json`	2,531,953,934
`Sanghuns-MacbookPro-M4Max.json`	2,532,361,686
`mini.json`	65,207,390

Both Mac.json and Sanghuns-MacbookPro-M4Max.json were around 2.5B. mini.json was 65M. It was not plausible that the Mac mini had suddenly used 40 times more tokens and landed at 2.5B. By scale alone, the two large files were almost certainly from the MacBook.

Second, exact daily equality. The today value in Mac.json for 2026-04-20 and the yesterday value in Sanghuns-MacbookPro-M4Max.json for the same date were identical, down to token counts, cost, and model breakdown. Two different machines do not accidentally produce the same breakdown at that level. The data came from the same projects directory.

So one MacBook was writing two files. The reason was now obvious: the filename depended on hostname, and the hostname was switching between two values.

The first fix failed

I deleted Mac.json as a stale file. That evening the status line was back at 5.1B. ls showed that Mac.json had been created again.

$ hostname -s
Mac

A few hours earlier the same command had returned Sanghuns-MacbookPro-M4Max. I had not switched machines or changed anything special about the network.

The idea that hostname could wobble like that ran against my intuition, so I checked it several times. The Mac mini always returned mini. Only the MacBook moved between names.

The three macOS names

macOS has three names.

ComputerName: the human-facing name shown in the GUI, such as Sanghun's MacbookPro M4Max.
LocalHostName: the Bonjour name, derived from ComputerName and ASCII-normalized, such as Sanghuns-MacbookPro-M4Max.
HostName: the RFC 1178 Unix hostname. It exists only if explicitly set. Otherwise it is empty.

$ scutil --get ComputerName
Sanghun's MacbookPro M4Max
$ scutil --get LocalHostName
Sanghuns-MacbookPro-M4Max
$ scutil --get HostName
HostName: not set

If HostName is set, the hostname command uses it. If it is not set, the command falls back depending on context. The fallback may be derived from LocalHostName, it may come from a hostname supplied by DHCP, or it may come from some other network stack default. On my MacBook, Mac was that default fallback. Depending on the network path, the command returned either Mac or Sanghuns-MacbookPro-M4Max.

The Mac mini, on the other hand, had HostName explicitly set to mini. No fallback was needed, so it stayed stable.

In short, hostname -s is not a reliable way to answer "which machine is this running on?" unless the machine has been configured in a way that makes it reliable. On a machine without HostName, it can drift.

Comparing alternatives

There were two broad fixes. One was to stabilize hostname. The other was to stop using hostname and pick a more stable device identifier.

Option	Upside	Downside
`sudo scutil --set HostName ...`	Fixes the root cause. The whole system benefits.	Requires sudo once. Some IT tooling may overwrite it.
`sysctl -n hw.model`	Kernel sysctl, stable, only a couple of script lines.	Less readable filenames, such as `Mac16,5.json`.
`ioreg` IOPlatformUUID	Truly unique.	UUID filenames are ugly.
Environment variable override	Human-chosen names.	Manual setup on every machine.
Per-device mapping table	Pretty names.	The table has to be maintained as devices change.

I chose sysctl -n hw.model for two reasons. First, the change was three lines in ccusage-cache.sh. Second, it did not require a system-wide change or sudo. A collision would require me to own two Macs with exactly the same model identifier and run Claude Code on both. That is not true now, and it is a rare future case.

The change

~/.claude/ccusage-cache.sh

# Before
HOSTNAME_SHORT="$(hostname -s 2>/dev/null | tr -d '\n\r' | tr -c 'a-zA-Z0-9.-' '_')"
[ -z "$HOSTNAME_SHORT" ] && HOSTNAME_SHORT="unknown"
CACHE_FILE="$USAGE_DIR/$HOSTNAME_SHORT.json"

# After
HOST_ID="$(sysctl -n hw.model 2>/dev/null | tr -d '\n\r')"
[ -z "$HOST_ID" ] && HOST_ID="unknown"
CACHE_FILE="$USAGE_DIR/$HOST_ID.json"

statusline-command.sh did not need any changes. Its aggregation logic already reads every *.json file in the directory, so the filename rule can change without touching the summing logic.

After deleting the stale file and running the script once, the MacBook produced the new file. Because ~/.claude is synced through Syncthing, the script change also reached the Mac mini automatically. On the Mac mini I only had to delete the old mini.json and run the script once.

The final state:

Mac16,5.json    # MacBook  (last30 = 2.54B)
Mac16,11.json   # Mac mini (last30 = 66M)

Total: 2.6B. The number I expected.

Side note: Apple changed model naming starting with M4

When I first saw Mac16,11, I was not sure it was the Mac mini. I was used to model identifiers that started with the product family, such as Macmini.

It turns out Apple removed the product-family prefix from model identifiers starting with the M4 generation. Older identifiers were readable, like Macmini9,1 or MacBookPro18,3. Now they are all MacN,X.

Mac16,5 = MacBook Pro 14-inch M4 Max
Mac16,11 = Mac mini M4 Pro

You cannot tell which file belongs to which machine just from the filename. Readability went down, but the trustworthiness of hw.model as a stable identifier went up. The old product-family prefix helped humans understand the category. Apple giving that up may also be a signal that product boundaries inside a generation are getting blurrier. Mac Studio overlaps with Mac Pro. Mac mini overlaps with Mac Studio.

Summary

Do not use hostname -s as a device identifier. On a Mac where HostName is not set, it can move between DHCP and LocalHostName fallbacks.

For this script, sysctl -n hw.model was the lightest replacement. No sudo, just a few lines of shell. The only cost is less readable filenames.

This article was originally published on Sanghun Kang’s blog.

Codex

Sanghun Kang — Fri, 02 Oct 2026 00:00:00 +0000

I don't write code.

Instead I tinker with a file called AGENTS.md. Instructions for an agent. When the agent makes a mistake, I add a line so it never makes that mistake again.

That file is what Codex reads.

The word codex comes from Latin caudex. A block of wood. Romans coated wooden tablets in wax and scratched words into them. Bound several together as a record. They called it a codex. When wood gave way to parchment, the name stayed.

In 529, Emperor Justinian compiled every decree scattered across the Roman Empire into one system. Not individual laws, but a law to govern laws. Every edict in one volume, so you only had to look in one place. They called it Codex Justinianus, a legal code.

In 2026, I'm building my own Codex Justinianus. Rules, lessons from failures, memory, all in one file so the agent only has to look in one place.

OpenAI shared a number on their blog this February. Three engineers. Five months. A million lines of production code. Lines written by humans: zero. What they wrote wasn't code. It was codex. Markdown wrapped around the agent. They call it harness engineering.

To use codex (the app), you first write your own codex (legal code). Not on parchment. On markdown. This codex is what codex (the agent) follows. I get a little nervous every time I open the IDE. Code I never wrote is following my codex. It runs fine. I didn't write a single line.

Legal code, agent, app. One word holds this tool's entire workflow. Whether whoever named it intended all of this, I have no idea.

Codex. Well named.

This article was originally published on Sanghun Kang’s blog.

Multilingual Ghost CMS Blog: 4. Making Tag Pages Multilingual

Sanghun Kang — Thu, 01 Oct 2026 02:21:10 +0000

Let's go to the news tag page.

https://{host}/tag/news/

If you open that tag page, it shows everything: Korean posts (#ko: ko news1, ko news2), English posts (#en: en news1, en news2), and posts without a language tag assigned (Comming Soon).

Let's look at routes.yaml again.

routes:

collections:
  /:
    filter: "tag:en"
    permalink: /{slug}/
    template: index-en
  /ko/:
    filter: "tag:ko"
    permalink: /ko/{slug}/
    template: index-ko

taxonomies:
  tag: /tag/{slug}/
  author: /author/{slug}/

routes.yaml

I set the English and Korean post paths completely differently. (/, /ko/)

But you cannot do that for tags. A tag cannot have multiple paths, and it is currently set to /tag/{slug}/. In other words, multilingual handling has to be done on a single page.

Let's implement the tag page like this to support multiple languages.

Show only posts with the language tag selected in the Language selector
Change the visible posts when the language is changed in the Language selector

0.0.4 · sanghunka/ghost-multilingual-theme@d603058 - Multilingual tag page

Change how the Language selector works

Right now, changing the Language selector value redirects to / or /ko/.

On the tag page, when the Language selector value changes, I will change it so that it does not redirect and instead shows only posts with the corresponding language tag.

Let's modify default.hbs so that the Language selector works differently depending on whether the page is a tag page or not.

{{ghost_foot}}

<script>
    function initializeLanguageSelector() {
        var selector = document.getElementById('languageSelector');
        var currentUrl = window.location.href;

        if (!currentUrl.includes('/tag/')) {
            var urlLanguage = currentUrl.includes('/ko/') ? 'ko' : 'en';
            localStorage.setItem('selectedLanguage', urlLanguage);
            selector.value = urlLanguage;
        } else {
            selector.value = localStorage.getItem('selectedLanguage') || 'en';
        }

        selector.style.display = 'block';

        selector.addEventListener('change', function() {
            localStorage.setItem('selectedLanguage', this.value);
            if (!currentUrl.includes('/tag/')) {
                window.location.href = this.value === 'ko' ? '/ko/' : '/';
            }
            else {
                window.location = window.location.href;
            }
        });
    }

    initializeLanguageSelector();
</script>

On lines 8 and 20, it checks whether the page is a tag page.
- if (!currentUrl.includes('/tag/'))
Line 13
- If it is a tag page, it does not check the URL and instead takes the selectedLanguage value currently stored in localStorage as is and sets that as the Language selector value. If that value does not exist, for example when accessing the page directly by URL, it sets the default value en.
- selector.value = localStorage.getItem('selectedLanguage') || 'en';
Line 24
- If it is a tag page, it does not redirect to /ko/ or / and simply refreshes the page.
- window.location = window.location.href;

The reason for refreshing is to show posts that match that language. Up to this point, applying this means that changing the Language selector value on the tag page will not redirect to /ko or /. However, it still will not show posts for that language. To do that, tag.hbs must be modified.

Modify tag.hbs

You can check the modified tag.hbs code at the link below.

ghost-multilingual-theme/multi/tag.hbs at d6030585a2b1a0ece111f6dbb7b434a147ba4005 · sanghunka/ghost-multilingual-theme - Contribute to sanghunka/ghost-multilingual-theme development by creating an account on GitHub.

The idea is as follows.

Templates are processed on the server side. You cannot use the localStorage value held on the frontend to fetch only posts in a specific language.
You have to use a method where you fetch everything first and then filter it.
On the tag page, a post has the form <div class="post-card">. Let's also include language information in that div and then filter it on the frontend.

But the problem is that there is no way in the template layer to know which language tag that post has. To solve this, there is a rule in this tutorial that was established in the first post.

💡Let's use the second tag as the position for the language tag

{{#foreach posts}}
    <div class="post-card" data-language="{{tags.[1].name}}">
        {{!-- The tag below includes the markup for each post - partials/post-card.hbs --}}
        {{> "post-card"}}
    </div>
{{/foreach}}

If you get the second tag (tags.[1].name), you can pass that post's language through the template layer.

Now let's look at the frontend part. First, all post-cards need to be hidden. Set opacity to 0. I added line 5 to create a smooth fade-in effect for posts when the language is changed in the language selector.

<style>
    .post-card-excerpt,
    div.post-card {
        opacity: 0; /* Initially set all post cards to be transparent */
        transition: opacity 0.5s ease; /* Transition for smooth display */
    }
</style>

For posts that match the condition, set opacity to 1 so they become visible.

<script>
document.addEventListener('DOMContentLoaded', function() {
    const selectedLanguage = localStorage.getItem('selectedLanguage') || 'en';  // Read language setting from local storage or use default 'en'
    const postCards = document.querySelectorAll('div.post-card[data-language]');
    let visibleCount = 0;
    postCards.forEach(card => {
        // Remove '#' character and update language setting
        const language = card.getAttribute('data-language');
        const cleanedLanguage = language.replace('#', '');
        card.setAttribute('data-language', cleanedLanguage);
        // Check if it matches the selected language, then show or hide
        if (cleanedLanguage !== selectedLanguage) {
            card.style.display = 'none';
        } else {
            visibleCount++;  // Count the number of posts that match the selected language
            setTimeout(() => {  // Use setTimeout for a smooth display
                card.style.opacity = 1;  // Set opacity to 1 to make the element visible
            }, 10);
        }
    });
    // Dynamically update text
    const collectionText = document.querySelector('.post-card-excerpt');
    if (collectionText) {
        const text = visibleCount === 0 ? 'zero posts' :
                    visibleCount === 1 ? '1 post' :
                    `${visibleCount} posts`;  // Set text based on the count
        collectionText.innerHTML = `A collection of ${text}`;  // Set text in HTML
        setTimeout(() => {  // Use setTimeout for a smooth display
            collectionText.style.opacity = 1;  // Set opacity to 1 to make the element visible
        }, 10);
    }
});
</script>

It gets the selectedLanguage value stored in localStorage, and if that value does not exist, it uses the default value 'en'.
The language tags are #en or #ko. The selectedLanguage value is en or ko. For direct comparison, let's remove all # characters from the data-language attribute.
If it does not match the condition, set display = 'none'. If it does match, change opacity = 1 to show the post.
While processing this, it counts the visibleCount value and displays on the screen how many posts there are.

Result

It was implemented just as I wanted. I think there may be a more concise way to handle the CSS, but with my knowledge, this seems to be the best I can do for now.

Going forward

Multilingual handling for the About and Author pages
Clicking the logo in the top left always redirects to /

There is still a lot left to handle. However, these are not areas that have a major impact on usability, so I plan to fix them gradually.

Multilingual Ghost CMS Blog: 5. Making Home Links Language Aware - This explains how to make the home links in the navigation bar, footer, and error page point to the correct language-specific homepage.

This article was originally published on Sanghun Kang’s blog.

DEV Community: Sanghun Kang

Multilingual Ghost CMS Blog: 9. Language Switching on Author and Post Pages

Adding multilingual handling to the Author page

author.hbs

assets/js/util.js

Moving to the translated post from a #multi post

partials/hreflang-multi.hbs

default.hbs

Limitations of Author page filtering

Result

How to Make Orca Codex Threads Appear in the ChatGPT App

The Problem

Root Cause

The Fix

Existing Orca Threads Are Not Migrated Automatically

Detours and Dead Ends

Multilingual Ghost CMS Blog: 8. Automating hreflang for #multi Posts

Rules for multilingual posts

partials/hreflang-multi.hbs

Calling the partial in post and page contexts

The problem that depended on tag order

Checking the result

Things to watch out for

Syncing Codex Settings and Conversation History Across Multiple Macs

What lives inside ~/.codex

Why not synchronize state_5.sqlite directly?

The actual problem

Syncthing setup

1. Install Syncthing

2. Connect the two machines

3. Register ~/.codex as a shared folder

4. Use an allowlist-style .stignore

Repairing a missing sidebar entry after JSONL arrives

Choosing the right trigger

First attempt: a five-minute LaunchAgent

Second attempt: Codex SessionStart and SessionEnd

Final approach: Syncthing ItemFinished events

Limitation: the running app's UI cache

LaunchAgent configuration

Manual reconciliation skill

Lessons learned

JSONL and the sidebar are different states

Run one complete repair when the listener starts

Active tasks change frequently

References

-update- 2026-10-09: Thread registration stopped after an app update

Use the current executable and discover it at runtime

Recovery and verification

Multilingual Ghost CMS Blog: 7. Adding hreflang

The hreflang needed for the home page

Why {{#is "home"}} did not solve it

Handling it with contentFor

index-en.hbs

index-ko.hbs

default.hbs

Checking the result

[App] Multiple Codex (ChatGPT) accounts on one machine

How

Why it works

Updates: automatic, on open

Caveat: passkey doesn't work

Multilingual Ghost CMS Blog: 6. Fixing Invisible Post Excerpts on Tag Pages

Cause

Updating tag.hbs

Result

[CLI] Multiple Codex (ChatGPT) accounts on one machine

How

Why it works

Caveat: the desktop app is a different story

Multilingual Ghost CMS Blog: 5. Making Home Links Language Aware

Full code

error-404.hbs

error.hbs

tag.hbs

default.hbs

Wrapping up

Hostname Is Not a Device Identifier

Did I really use that many tokens?

The aggregation setup

Catching the duplicate with data

Moving to the translated post from a `#multi` post

Why `{{#is "home"}}` did not solve it