DEV Community: upa_rupa

[iTerm2] Send Clipboard Images and Files to and from SSH Hosts with a Single Keystroke

upa_rupa — Thu, 22 Oct 2026 10:18:11 +0000

The Problem

I run Claude Code and Codex on remote servers over SSH, and I constantly want to say "look at this screenshot" or "check this local file."

Locally, that's just ⌘V or Ctrl+V. Over SSH, it turns into a chore:

Take a screenshot and save it to a local file first (or dig up the file in Finder)
Send it to the server with scp
Type the remote path by hand (and inevitably make typos)

The reverse is just as bad. When an agent replies "I created the report: /home/dev/tmp/report.pdf", I have to retype that path into scp to bring the file back.

I'm usually connected to several remote machines at once, giving instructions to a different agent on each, so I did this all day long and it was driving me up the wall.

Tools Exist for Images, but Not Quite What I Wanted

If all you need is to paste images to an SSH host, there are plenty of good tools: imgssh, clipssh, cc-clip (Japanese), clipaste, claude-ssh-image-skill, and more.

But every one of them only sends clipboard images. I also wanted to send PDFs and folders, and to download logs. Finding a tool that roughly fits, installing it, configuring it, and living with whatever it lacks takes effort. Since I knew exactly what I wanted, I had AI build it instead.

What I Ended Up With

⌘⇧V: From the Mac to the SSH Host

Take a screenshot to the clipboard (⌘⇧⌃4), or select files or folders in Finder and press ⌘C (multiple items are fine)
Press ⌘⇧V in a tab connected over SSH

The images, files, or folders land in ~/tmp/ on the remote host, and their full paths are typed into the terminal. They go wherever the cursor is, whether that's a shell or Claude Code's input box, so you can drop them into a command or add a sentence around them and send.

# Transfer and cd in one go
$ cd "/home/dev/tmp/spec_docs"

# Move it wherever you like
$ mv "/home/dev/tmp/spec_docs" spec_docs

⌘⇧D: From the SSH Host to the Mac

Select a path shown on screen with the mouse and press ⌘⇧D, and the file lands in ~/Downloads on the Mac. Folders work too. No need to copy anything.

Even if the path wraps onto two lines on screen, just select it as is
If the selection is a URL, it opens in the Mac's browser

Folders and Large Files

The destination or source is the SSH host the current tab is connected to. Switch tabs to work with a different machine
Transferring folders or files larger than 10 MB triggers a confirmation dialog and displays a progress window

Making It My Own as I Go

With an off-the-shelf tool, you either adapt to the author's way of thinking or go hunting through settings. When the tool was built just for you, you simply tell the AI on the spot whenever something bugs you. Here are a couple of things I actually said:

"Don't we need to handle macOS dakuten and handakuten?": File names created in Finder can store a character like "パ" decomposed into "ハ" + "゜" (NFD). On Linux, that becomes a different name from the visually identical composed "パ", so I had it convert names to the composed form (NFC) when sending.
"Make it work even when a path wraps and a space sneaks in": When you select a path that the screen has wrapped, it now strips the inserted space and treats it as the correct path.

A general-purpose tool would probably let you choose the download folder in a config file or settings screen, for convenience. But when an AI agent is doing the building, even if it's hardcoded, saying "save it here" is the configuration. There's no need to build a settings feature at all.

How to Use It

The scripts are on GitHub:

archelon-inc/iterm2-ssh-transfer

git clone https://github.com/archelon-inc/iterm2-ssh-transfer.git ~/iterm2-ssh-transfer

1. Assign the Keys

In iTerm2, go to Settings → Keys → Key Bindings, press +, and set up each script like this:

Keyboard Shortcut: ⌘⇧V and ⌘⇧D (or whatever you prefer)
Action: Run Coprocess
The field below it (Enter command to run): /Users/<your user name>/iterm2-ssh-transfer/upload.sh and {same folder}/download.sh

Don't add any arguments. Set the dropdown at the bottom of the editor to apply to the current session only. With "Apply to all sessions", a single key press runs the script in every open tab at once.

2. Let SSH Connect Without Asking for a Password

The scripts open a separate ssh connection in the background, so they can't answer a password prompt. You need ssh to connect without asking for a password or passphrase. A key without a passphrase would work, but that's a bit much, so here's what I do instead.

The first ssh connection you open to a host becomes the "master", and the scripts' ssh connections piggyback on it. Just add this to ~/.ssh/config:

Host *
  ControlMaster auto
  ControlPath ~/.ssh/cm-%C

When you run ssh <host> in a tab, that connection becomes the master. That's the only time you're asked for the passphrase
When the scripts connect in the background, they ride on the master connection, so no further authentication is needed
Since there's no ControlPersist, closing the master connection ends the piggybacking. Connecting without authentication only works while the tab is connected
As a bonus, the scripts reuse the existing connection instead of opening a new one, so there's no connection wait, even through a jump host

One quirk: if you connect to the same host from a second tab, it also piggybacks on the first tab. If you then exit in the first tab, it won't finish and keeps waiting until you close the second tab.

3. Raise the Selection Size Limit

Under Settings → Advanced, increase "Maximum number of bytes of selection to provide to Python API". Even if you leave it at the default of 100, ⌘⇧D will tell you with a dialog when you select a long path and open this setting for you.

Caveat: How Far It Reaches

The destination or source is the host you connected to directly from the Mac. It also works through a jump host (ProxyJump) and in tabs using iTerm2's tmux integration (tmux -CC). However, it can't reach a host you ssh into again after logging in to the remote. That ssh runs on the remote host, and the Mac can't see it.

Tested on macOS 27.0.1.

Wrapping Up

Just copy and press ⌘⇧V, or select and press ⌘⇧D. It's surprisingly convenient. Getting a screenshot in front of Claude Code takes a few seconds, and opening files the agent created on my Mac is a breeze.

While writing this, I realized that articles like this used to be mostly about how the thing is implemented. Now that AI does the implementing, that's not very meaningful. So this time I wrote it from the angle of "here's something handy to have AI build for you."

If it looks useful, fork the repository and have AI adapt it to your own environment and taste.

This article was originally published in Japanese at archelon-inc.hatenablog.com.

VS Code Remote SSH: Automatically Invoke VS Code as Your Editor from External Terminals

upa_rupa — Tue, 28 Apr 2026 06:53:06 +0000

The Problem to Solve

VS Code Remote (SSH) is powerful, but there are situations where you want to handle terminal operations in your favorite external terminal like iTerm2 instead of the integrated terminal.

However, when working from an external terminal, you can't seamlessly use VS Code as your editor out of the box.

Open files with code <filename> from external terminals like iTerm2, Alacritty, or WezTerm
Use VS Code as the editor for git commit or crontab -e, but automatically fall back to another editor when VS Code isn't running

This article introduces a wrapper script that solves both.

Background: Why `code` Doesn't Work from Terminals Outside VS Code

Inside VS Code's integrated terminal, environment variables for communicating with the VS Code server (VSCODE_IPC_HOOK_CLI) and paths to dedicated executables are set automatically.

These aren't inherited by external terminals, though. So simply running the code command won't actually "open the file in a VS Code window."

This issue is well known, and there are existing articles offering solutions:

A common approach is to write the socket lookup in .zshrc or .bashrc — both references above take this route. The downside is that it's evaluated once at shell startup, so it can't keep up when VS Code is started or restarted afterward. The Vinnie article works around this by wrapping the lookup in a shell function you can re-run manually, but neither reference handles the case where VS Code isn't running at all.

In this article, we'll put the lookup in a standalone script that re-evaluates on every invocation and gracefully falls back to another editor when VS Code isn't running.

The Solution: A Wrapper Script Called `editor`

First, create a directory to hold the script (e.g., ~/bin) and save the following as editor.

Creating the Script

#!/bin/bash
# Find the most recent IPC socket
export VSCODE_IPC_HOOK_CLI=$(ls -t /run/user/$(id -u)/vscode-ipc-*.sock 2>/dev/null | head -1)
# Get the path to the VS Code CLI executable
vscode_code=$(ls -td ~/.vscode-server/cli/servers/*/server/bin/remote-cli/code 2>/dev/null | head -1)

# When VS Code is available
if [ -S "$VSCODE_IPC_HOOK_CLI" ] && [ -n "$vscode_code" ]; then
  if [ $# -eq 0 ]; then
    # Running `code` with no arguments often just exits silently,
    # so prompt the user to specify a file when invoked as an editor
    echo "When using VS Code, please specify a file: editor <filename>"
    exit 1
  fi
  # VS Code may be hidden behind other windows or take a moment to surface
  echo "Opening in VS Code..."
  # --wait blocks until the file is closed in VS Code
  "$vscode_code" --wait "$@" >/dev/null 2>&1
  exit $?
else
  # If VS Code isn't available, fall back to another editor (nano, vim, etc.)
  nano "$@"
fi

Granting Execute Permission

chmod +x ~/bin/editor

Shell Configuration

Make the script callable from anywhere and register it as the system's default editor. Add the following to your .zshrc or .bashrc:

# Add ~/bin to PATH (if not already)
export PATH="$HOME/bin:$PATH"

# Register as the default editor
export EDITOR="$HOME/bin/editor"
export VISUAL="$HOME/bin/editor"

How It Works

Auto-discovering the Latest Socket

You could hardcode the socket path in .zshrc, but it changes every time VS Code restarts and breaks. This script looks under /run/user/ on every invocation, so it adapts to whatever the current connection state is.

Use from External Terminals

With this script in place, you don't have to think about whether you're inside VS Code's integrated terminal. Just type editor in your favorite external terminal and VS Code opens the file.

Handling No-Argument Invocation

Running code with no arguments simply exits. That's confusing when invoked as an editor — nothing happens — so the script prints a hint instead.

Programs differ in whether they read EDITOR or VISUAL. Many tools, including git and crontab, prefer VISUAL, but some only check EDITOR. Setting both is the most reliable approach.

Where This Helps

Once EDITOR/VISUAL point at this script, VS Code is automatically used in situations like:

git commit — Editing commit messages
git rebase -i — Interactive rebase operations
crontab -e — Editing crontabs
Ctrl+x, Ctrl+e — Bash/Zsh command-line editing
Claude Code's Ctrl+X, Ctrl+E — Launching an external editor for prompt input

If VS Code isn't running when you invoke any of these, nano (or whatever you configured) takes over, so your workflow doesn't stall.

Behavior Summary

State	`editor file.txt`	`editor` (no arguments)
VS Code running	Opens in VS Code	Shows a guidance message
VS Code not running	Opens in nano	Opens in nano

Closing Thoughts

I love VS Code, but iTerm2's tmux integration (tmux -CC) is so handy that I often skip the integrated terminal entirely. Even then, I still want VS Code for actual file editing, and this wrapper made that workflow much smoother. Getting Copilot completions while editing crontabs is a quietly nice bonus.

It's a small piece of configuration, but if you're a fellow VS Code user in the same situation, hopefully this is useful.

This article was originally published in Japanese at archelon-inc.hatenablog.com.

The Nine-Year Journey to the Orca Emoji (U+1FACD) — How a Single Character Moved the World

upa_rupa — Thu, 23 Apr 2026 05:18:26 +0000

I love orcas, so I always felt a bit sad that while we had whale (🐋) and dolphin (🐬) emojis, there was no orca. Then recently, I came across news that the orca emoji would be introduced in iOS 26.4^[1]. Since emoji aren't an Apple-proprietary thing — they're defined by an international standard called Unicode — I knew this had to be a bigger story. So I dug in.

What I found was the story behind the new orca emoji 🫍: a nine-year campaign by people around the world pushing for its adoption into the Unicode standard.

Basic Info

Field	Details
Code Point	U+1FACD
Name	ORCA
Block	Symbols and Pictographs Extended-A
Standard Version	Unicode 17.0 / Emoji 17.0
Release Date	September 9, 2025

This emoji was added as a new standalone code point^[2] — not expressed by combining existing emoji, but assigned its own unique code: U+1FACD.

2016–2017: Voices Rise Around the World

The orca emoji story begins well before any official proposal, and in multiple places at once.

In August 2016, Jökull Ingi Þorvaldsson from Iceland started an online petition on Change.org called "Make a Killer Whale Emoji," asking Apple to add an orca emoji^[4]. It gathered 39 signatures.

The following February (2017), Christoph Päper, a Unicode contributor from Germany, opened an issue titled "Orca emoji" on the GitHub Unicode proposals tracker (Crissov/unicode-proposals)^[3]. His point: we have whale (🐋) and dolphin (🐬) emoji — why not orca? The issue included a link to the Change.org petition above.

The voices were there. But voices alone don't create emoji. A formal proposal had to be submitted to the Unicode Consortium.

February 2019: A Third Person Steps Up

In 2019, a Spanish developer named Marcos Del Sol Vives turned these feelings into a formal proposal^[5].

On February 20th, Marcos submitted a proposal for the orca emoji to the Unicode Consortium's Emoji Subcommittee (ESC). He had no connection to Jökull in Iceland or Christoph in Germany — he was a third, independent voice.

Then in September 2020, Lukas Ewert in Germany (also independently) launched another Change.org petition, "Make Orcas an Emoji," collecting 356 signatures^[15].

People around the world, strangers to each other, were all asking for the same thing: an orca emoji.

Marcos's proposal followed the format Unicode requires and made a compelling case^[6].

Search Popularity Comparison

Using Bing search trends, Marcos showed that "orca" had roughly the same search popularity as "elephant." Elephants already have an emoji (🐘) — orcas don't. He quantified the gap.

No Existing Emoji Covers It

Unicode's proposal review includes an "exclusion factors" section, where proposers must argue why their submission shouldn't be excluded. Marcos addressed this directly^[6].

"Can't an existing emoji substitute?" — No. Orcas are commonly called "killer whales" but are scientifically members of the dolphin family, and they look quite different from whales. "Too specialized?" — Pufferfish, crickets, and swans already have emoji, so orca can't be considered too specialized. "Just a passing trend?" — Orcas have existed on Earth for about 11 million years, the proposal notes.

Sample Images

Following Unicode Consortium requirements, Marcos prepared sample images at 18×18 and 72×72 pixels, in both black-and-white and color.

2019–2023: The Gate Is Closed

From here, Marcos's proposal entered a long wait.

The proposal was sent in 2019. But the formal document number L2/24-249 wasn't registered in the Unicode document registry until 2024^[6]. There is no orca-related document anywhere in the 2019 Document Register^[7].

So what happened during those five years? Looking into it, what emerged wasn't simple neglect — it was a deliberate decision on Unicode's part.

The Iron Rule: Once Added, Never Removed

First, some background: Unicode has an absolute rule called the Stability Policy^[17].

Once a character is encoded, it will not be moved or removed.

This means that once a code point is assigned, it stays there as long as humanity uses this standard — forever. Mistakes cannot be undone. This is the foundation of Unicode's caution around adding emoji.

A Strategic Pause — Shifting to Quality Over Quantity

In 2020, the COVID-19 pandemic pushed back the Unicode 14.0 release by six months^[2]. Then in autumn 2022, the UTC (Unicode Technical Committee) announced that Unicode 15.1 would be a limited release.

ESC chair Jennifer Daniel saw this as an opportunity. Her January 2023 blog post, "Breaking the Cycle"^[18], stated:

emoji categories are about to hit or have hit a level of saturation.

the ESC approves fewer and fewer emoji proposals every year.

The ESC used this pause to tackle longstanding issues: unifying skin tone variations, redesigning family emoji, and improving bidirectional text support. They also decided to temporarily delay the Unicode 17.0 submission window until April 2024^[18].

This wasn't a shutdown from neglect. It was a deliberate pause to redefine the emoji addition process itself.

Marcos's Proposal, Waiting at the Gate

There is no record of the orca emoji being rejected. It doesn't appear on Charlotte Buff's list of rejected emoji proposals^[10], nor in the official Unicode non-approval notice archive^[11].

Marcos's proposal wasn't denied. The gate was simply closed.

2024: The Gate Reopens

On April 2, 2024, submissions reopened with new guidelines^[8]. ESC chair Jennifer Daniel announced the reopening^[9].

When the gate opened, Marcos's proposal — waiting since 2019 — finally received its formal document number, L2/24-249^[6]. Later that year in November, the ESC proposed 164 new emoji candidates to the UTC, including the orca^[12]. Of those 164: 9 new code points and roughly 155 skin tone variations of existing emoji. One of the new code points — the Apple Core — was ultimately withdrawn, and the remaining 163 were approved as Emoji 17.0.

No objections were submitted during the Public Review Issue (PRI #515) for Emoji 17.0 candidates^[16].

September 9, 2025: Official Adoption

As part of Unicode 17.0 / Emoji 17.0, the orca emoji was officially approved^[2]. About nine years from the first online petition; about six and a half years from Marcos's proposal.

Marcos himself hasn't spoken publicly much about the details of this journey. His site orca.pet records the fact of the proposal and the fact of adoption — simply^[5].

The Emoji Approval Process: Open, but Careful

Unicode's emoji approval process is designed to be transparent^[13].

Submit a proposal: Anyone can submit an emoji proposal
ESC review: The Emoji Subcommittee evaluates proposals and decides whether to recommend them to the UTC
UTC deliberation: Discussed by the technical committee; meeting notes are published
Draft candidate list: Before final approval, a candidate list is published as a Public Review Issue (PRI), open for public feedback, which is also published^[16]
Official release: Released as a new version of the Unicode standard

All proposals are published as PDFs on unicode.org and available for anyone to read^[6].

Given that an assigned code point can never be removed, this caution has good reason. As the orca's case shows, years between proposal and adoption aren't unusual. But that's not negligence — it's a reflection of the weight of defining a standard that will be used, permanently, across the world.

Platform Support Status (as of March 2026)

Platform	Status
Google Noto Color Emoji	Supported (v2.051, released September 12, 2025)^[14]
Apple (iOS / macOS)	In beta with iOS 26.4 / macOS 26.4; stable release expected March–April 2026^[1]
X (formerly Twitter)	Supported (Twemoji v17.0)
Microsoft (Windows)	Not yet supported; as of March 2026, just reached Emoji 16.0 support

Unicode defines the code point and meaning, but the visual design is left to each platform (Apple, Google, Samsung, etc.). That's why the same U+1FACD looks different on iPhone versus Android.

Display Test with Noto Color Emoji

This article loads Google's Noto Color Emoji font to test rendering of the new orca emoji.

🫍

Even if your browser or OS doesn't support Unicode 17.0 emoji yet, you should see it rendered via Noto Color Emoji. If you can see a large orca above, it's working.

Summary

The orca emoji (🫍) was born from independent voices in Iceland, Germany, and Spain — and took nine years to make it into the Unicode standard
Proposer Marcos Del Sol Vives built a case backed by search data and comparative arguments
The five-year gap wasn't neglect — it was a deliberate pause for Unicode to confront emoji saturation and redefine the addition process
Unicode's emoji approval process is transparent, but the Stability Policy demands care

Every emoji we casually use has a story behind it. And those stories are often less about triumph than about patience and a series of coincidences stacking up over time.

References

iPhone Mania, "iOS26.4で利用可能になる新絵文字のデザインが明らかに！ (Japanese)" March 10, 2026. https://iphone-mania.jp/ios-600850/
The Unicode Blog, "Unicode 17.0 Release Announcement," September 9, 2025. http://blog.unicode.org/2025/09/unicode-170-release-announcement.html
Crissov/unicode-proposals, "Issue #103: Orca emoji," GitHub, February 5, 2017. https://github.com/Crissov/unicode-proposals/issues/103
Jökull Ingi Þorvaldsson, "Make a Killer Whale Emoji," Change.org, August 2016. https://www.change.org/p/apple-make-a-killer-whale-emoji-in-apple-s-emoji-board
Marcos Del Sol Vives, "Orca emoji," orca.pet. https://orca.pet/emoji/
Marcos Del Sol Vives, "Proposal for Orca Emoji," Unicode Document L2/24-249, 2024. https://www.unicode.org/L2/L2024/24249-orca-emoji.pdf
The Unicode Consortium, "UTC Document Register — 2019." https://www.unicode.org/L2/L2019/Register-2019.html
The Unicode Blog, "Emoji Submissions Intake Process Re-opening," March 2024. http://blog.unicode.org/2024/03/emoji-submissions-intake-process-re.html
Jennifer Daniel, "Emoji submissions re-opening," Substack. https://jenniferdaniel.substack.com/p/emoji-submissions-re-opening-april
Charlotte Buff, "Rejected Emoji Proposals." https://charlottebuff.com/unicode/misc/rejected-emoji-proposals/
The Unicode Consortium, "Archive of Notices of Non-Approval." https://www.unicode.org/alloc/nonapprovals.html
Emojipedia Blog, "What's New In Unicode 17.0." https://blog.emojipedia.org/whats-new-in-unicode-17-0/
The Unicode Consortium, "Submitting Emoji Proposals." https://unicode.org/emoji/proposals.html
Emojipedia Blog, "Google Debuts Emoji 17.0 Support." https://blog.emojipedia.org/google-debuts-emoji-17-0-support/
Lukas Ewert, "Make Orcas an Emoji," Change.org, September 2020. https://www.change.org/p/apple-make-orcas-an-emoji
The Unicode Consortium, "PRI #515: Unicode Emoji 17.0 Alpha Repertoire." https://www.unicode.org/review/pri515/
The Unicode Consortium, "Unicode Character Encoding Stability Policies." https://www.unicode.org/policies/stability_policy.html
Jennifer Daniel, "Breaking the Cycle," The Unicode Blog, March 8, 2024 (originally published January 17, 2023). http://blog.unicode.org/2024/03/breaking-cycle.html

This article was originally published in Japanese at archelon-inc.hatenablog.com.

Auto-Configure Git Hooks for Your Entire Team with Just npm install

upa_rupa — Wed, 22 Apr 2026 08:58:49 +0000

No more "Git hooks weren't working on my machine"

In team development, running tests locally before pushing is crucial — it reduces CI wait times and helps you move faster.

The problem? The .git/hooks/ directory is not tracked by Git. Every developer has to manually set up hooks after cloning a repo, which leads to familiar issues:

Forgotten setup: New team members or people rebuilding their environment skip the manual step
Stale hooks: When hook scripts are updated, getting everyone to re-apply the changes manually is a losing battle
No enforcement: Hook setup is left to individual discretion, making it hard to guarantee consistent quality across the team

Even with CI in place, slow feedback loops hurt if local checks keep getting skipped.

The fix: embed Git hook setup into npm install — an operation everyone already runs — so the entire team stays in sync without thinking about it.

And we'll do it without any extra libraries like Husky, using only Git's built-in features and npm scripts.

Local Git hooks and GitHub Actions: Better Together

Running tests locally doesn't replace CI — they serve different purposes and work well together.

Aspect	GitHub Actions	Local Git hooks
When it runs	After push	Before push
Feedback speed	Must wait for CI to spin up	Instant, right on your machine
Environment consistency	Unified, reproducible environment	Depends on local setup
Enforcement	Strong (cannot be bypassed)	Medium (`--no-verify` can skip it)
Resource cost	Consumes CI minutes	Only your local machine

Fast local feedback plus reliable CI checks — together they cover both speed and consistency.

The Setup: core.hooksPath + npm prepare

Just three steps:

1. Create a hooks directory in your project

mkdir -p .githooks

2. Write your hook scripts

Example: a pre-push hook that runs tests before every push

# .githooks/pre-push
#!/bin/bash

echo "🧪 Running tests before push..."

# Run project tests
npm test

if [ $? -ne 0 ]; then
  echo "❌ Tests failed. Push aborted."
  exit 1
fi

echo "✅ All tests passed. Proceeding with push."

Make it executable:

chmod +x .githooks/pre-push

3. Add a prepare script to package.json

{
  "scripts": {
    "prepare": "git config core.hooksPath .githooks"
  }
}

That's it.

Why This Works

How prepare behaves:

Runs automatically after npm install
Also runs after npm ci
Running npm install right after cloning is second nature — making this a reliable trigger

What core.hooksPath does:

Points Git to any directory instead of the default .git/hooks/
By pointing to .githooks/ in the project root, the hook scripts themselves become Git-tracked — updates to scripts propagate to everyone via the repository

Combined: clone the repo, run npm install, and Git hooks are active. No extra steps.

Simpler Onboarding for New Team Members

The old way:

Clone the repository
npm install
"Oh, the README says to set up Git hooks..."
Manually run git config core.hooksPath .githooks
(Half the team forgets)

With this setup:

Clone the repository
npm install ← done

Onboarding instructions become: "just run npm install."

Monorepo Support

If you have multiple sub-projects under a single root:

project-root/
├── .githooks/
│   └── pre-push
├── frontend/
│   └── package.json
├── backend/
│   └── package.json
└── package.json  ← configure here

Configure it in the root package.json and it works as long as you run npm install at the root.

A Real-World pre-push Hook

#!/bin/bash

echo "🧪 Running pre-push checks..."

# Frontend tests
if [ -d "frontend" ]; then
  echo "📦 Testing frontend..."
  cd frontend && npm test
  if [ $? -ne 0 ]; then
    echo "❌ Frontend tests failed."
    exit 1
  fi
  cd ..
fi

# Backend tests
if [ -d "backend" ]; then
  echo "📦 Testing backend..."
  cd backend && npm test
  if [ $? -ne 0 ]; then
    echo "❌ Backend tests failed."
    exit 1
  fi
  cd ..
fi

echo "✅ All checks passed!"

Summary

Don't rely on CI alone — run tests locally for fast feedback
Create a .githooks/ directory and place your hook scripts there
Set "prepare": "git config core.hooksPath .githooks" in package.json
Everyone on the team gets Git hooks automatically on npm install

Pushing without running tests becomes the exception, not the norm — and "I forgot to set up hooks" stops happening.

This article was originally published in Japanese at archelon-inc.hatenablog.com.

How to Match Only `/` in CloudFront Using `/?*`

upa_rupa — Tue, 21 Apr 2026 10:30:52 +0000

Introduction

When building a site on AWS CloudFront, a common requirement arises: "I want to route only the root (/) to a specific origin, or apply unique logic strictly to that path."

The challenge is that CloudFront’s path patterns lack a way to match exactly /. Typically, you end up relying on the Default Behavior (*), which captures everything from scripts to styles. This makes it difficult to separate caching strategies or route requests to different origins cleanly.

This article explores a clean way to solve this by taking advantage of the specific behavior of the ? wildcard: using the /?* pattern to isolate the root path.

The Constraint: CloudFront Path Patterns

CloudFront’s routing relies on path patterns with specific limitations:

No regular expressions
Two available wildcards:
- *: Matches any string of 0 or more characters.
- ?: Matches exactly one character.
Priority-based evaluation: The first pattern to match a request wins.

Within these constraints, the goal is to find a way to express “everything except the root” so the root itself can be handled independently.

How the Pattern Works

The key lies in the strict "exactly one character" rule of the ? wildcard.

Breaking Down the Pattern

The /?* pattern works as follows:

/ — A literal slash.
? — Exactly one character (required).
* — Any string of 0 or more characters.

This means that /?* matches any path that has at least one character following the initial slash.

💡 The Mechanism

By assigning /?* a higher priority, you ensure that only the root request (/)—which has zero characters after the slash—does not match and falls through to the Default Behavior (*).

Matching Results

Path	Matches `/?*`?	Reason
`/index.html`	✅ Yes	Matches `/` + `i` + `ndex.html`
`/main.js`	✅ Yes	Matches `/` + `m` + `ain.js`
`/assets/style.css`	✅ Yes	At least one character follows the slash
`/`	❌ No	Zero characters follow the slash

Fine-Grained Routing: SSR vs. Static Assets

The most practical application is a hybrid setup (e.g., Astro, Next.js), where you need to separate dynamic rendering from static delivery.

/ (Root): Route to a dynamic origin (Lambda, App Runner, etc.) to serve dynamic content and generate SEO metadata.
Everything else (/assets/*, /favicon.ico, etc.): Serve directly from S3 for maximum performance and lower costs.

Without this pattern, you’d need to manually enumerate every file extension. With /?*, you get a robust, catch-all solution for assets.

CDK Implementation Example

This approach keeps your infrastructure-as-code clean and easy to reason about:

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

const distribution = new cloudfront.Distribution(this, 'MyHybridDist', {
  // 1. Default (*) Behavior — Lowest Priority
  // Only the root (/) falls through to here.
  defaultBehavior: {
    origin: new origins.HttpOrigin('ssr-api.example.com'), 
    cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED, // SSR requires fresh data
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors: {
    // 2. Everything except root (/?*) — Higher Priority
    // Serve and cache all static assets from S3.
    '/?*': {
      origin: origins.S3BucketOrigin.withOriginAccessIdentity(assetBucket),
      cachePolicy: cloudfront.CachePolicy.CACHING_OPTIMIZED,
      viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    },
  },
});

Strategic Advantages

Zero-Maintenance Asset Routing: No need to update your config when adding new file types (.webp, .avif, etc.).
Architectural Clarity: The logic for your "Entry Point" and your "Assets" is split cleanly at the edge.
Optimized Caching: Apply a no-cache policy to your dynamic root while keeping aggressive, long-term caching for everything else.

⚠️ A Subtle but Crucial Limitation

When combining this with CloudFront Functions, keep in mind:

Rewriting request.uri within a Function does not trigger a re-evaluation of cache behaviors.

If a request hits the Default Behavior (*) and your Function rewrites the URI to /index.html, CloudFront will not move that request over to the /?* behavior. Execution stays within the behavior that matched the original request.

Summary

The ? wildcard in CloudFront is often overlooked, but it can be surprisingly powerful. Its strictness allows for an elegant implementation of path-based negation.

Whether you are managing SSR setups, multilingual redirects, or maintenance pages, /?* is a reliable tool for handling the root path as a first-class citizen in your routing logic.

This article was originally published in Japanese on archelon-inc.hatenablog.com.

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

upa_rupa — Tue, 21 Apr 2026 10:01:18 +0000

Introduction

In the Google Groups web interface, you’ll see three main reply options:

"Reply to all," "Reply to author," and "Forward."

Have you ever used "Reply to author"?

There’s one important thing to keep in mind: the messages you send aren’t automatically saved for you to access later.

What Actually Happens

When you click "Reply to author" in Google Groups, it opens a window to send a direct email to the original poster. You write your message, hit send—and then:

It won’t appear in the group archive — because it’s treated as a private email.
It won’t appear in your Gmail Sent folder — because the message is sent through Google Groups rather than your own Gmail account.

In short, you won’t have any way to review that message afterward.

Since there’s no record in your "Sent" folder or the group history, you can’t double-check what you wrote or confirm it was successfully delivered. You’re left waiting for a response without a paper trail.

Why Does This Happen?

Google Groups was originally designed as a bulletin board system, but many people use it like a mailing list. Because the interface feels like email, it’s natural to expect sent messages to be saved—this is where the confusion starts.

Action	How it's handled	History
Reply to all	Posted to the entire group	Saved in the group archive
Reply to author	Sent as a private message	Not saved in the group or Gmail

"Reply to author" sends a direct email through the Google Groups platform. Since your own email client isn't the one sending it, no copy is kept in your Sent folder.

Watch Out for Delivery Settings

Your email delivery settings can make this even easier to run into.

If your subscription is set to "Digest," multiple posts are bundled into a single email. To reply to a specific post, you often have to open the Google Groups web interface—which makes it much more likely you’ll click "Reply to author" by mistake.

A Known Issue for Users Worldwide

This is a well-documented issue. The Google Help Community contains many threads from users reporting this exact confusion.

For example, a thread titled "How can I see replies to author (a la Sent Messages)" has over 130 "I have the same question" votes. A Gold Product Expert confirmed that Google Groups does not provide a Sent folder or a built-in way to review these messages.

Even the official help page, "Compose or reply to a message," explains how to use the feature but doesn't explicitly mention that your messages won't be saved.

How to Avoid This

The Reliable Fix: Reply via Gmail

Avoid using "Reply to author" on the web interface. Instead, open the notification email in your Gmail inbox and reply directly from there.

When you send from Gmail, the message is saved in your Sent folder just like any other email.

Other Workarounds

BCC yourself (if the option is available)
Copy and save your message before hitting send
Manually add your own email address as a recipient

Summary

The "Reply to author" button might look convenient, but it lacks the basic record-keeping we expect from modern email. To ensure you always have a copy of your correspondence, get into the habit of replying directly from your email client. Don't let your important messages become "sent and forgotten" without a trace!

Getting 404 Errors After Building a Teams Tab App? HTML Caching Might Be the Cause

upa_rupa — Tue, 31 Mar 2026 10:47:14 +0000

Introduction

When developing Microsoft Teams tab apps, there's a frustrating issue you may run into during local development.

After modifying frontend code and rebuilding, Vite/Rollup adds a content hash to filenames (e.g., TeamsInitializer.bBRVpIft.js). However, if the browser (Teams WebView) has cached the HTML, the old HTML continues to reference the old hashed filenames, which results in 404 errors.

In this article, we'll share a solution we discovered by digging into the internal structure of the Teams SDK v2 local server.

Common Solutions and Their Drawbacks

Approach 1: Remove Hashes from Filenames

// astro.config.mjs or vite.config.js
export default {
  vite: {
    build: {
      rollupOptions: {
        output: {
          entryFileNames: 'assets/[name].js',
          chunkFileNames: 'assets/[name].js',
          assetFileNames: 'assets/[name].[ext]',
        },
      },
    },
  },
};

Drawback: Removing hashes means the browser may cache files indefinitely, preventing code updates from being reflected. You lose the benefits of cache busting.

Approach 2: Use the Dev Server (HMR)

Using Vite or Astro's dev server with HMR (Hot Module Replacement) avoids caching issues altogether.

Drawback: Teams apps are typically configured so that the Teams client (WebView) accesses a specific port, making it difficult to use the dev server's separate port directly.

Investigating the Teams SDK v2 Internals

When looking into the @microsoft/teams.apps package in Teams SDK v2, we discovered that HttpPlugin uses Express internally.

// Excerpt from node_modules/@microsoft/teams.apps/dist/plugins/http/plugin.js
const express_1 = __importDefault(require("express"));

let HttpPlugin = class HttpPlugin {
    constructor(server, options) {
        this.express = (0, express_1.default)();
        // ...
        this.use = this.express.use.bind(this.express);  // ← use() is exposed!
    }

    static(path, dist) {
        this.express.use(path, express_1.default.static(dist));
        return this;
    }
}

Key findings:

HttpPlugin holds an internal Express instance
The use() method is exposed and bound to Express's app.use()
This means we can add arbitrary Express middleware

Solution: Set Cache-Control Headers via Middleware

Leveraging this discovery, we add middleware to disable HTML caching only during local development.

// src/index.ts
import fs from "fs";
import https from "https";
import path from "path";

import { App, HttpPlugin, IPlugin } from "@microsoft/teams.apps";
import { ConsoleLogger } from "@microsoft/teams.common/logging";

const sslOptions = {
  key: process.env.SSL_KEY_FILE ? fs.readFileSync(process.env.SSL_KEY_FILE) : undefined,
  cert: process.env.SSL_CRT_FILE ? fs.readFileSync(process.env.SSL_CRT_FILE) : undefined,
};

const httpPlugin = new HttpPlugin(
  sslOptions.cert && sslOptions.key ? https.createServer(sslOptions) : undefined
);

// Disable HTML caching for local development only
if (!process.env.RUNNING_ON_AZURE) {
  httpPlugin.use("/tabs", (req, res, next) => {
    // Disable caching for HTML files and index.html requests
    if (req.path.endsWith(".html") || req.path === "/" || !req.path.includes(".")) {
      res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate");
      res.setHeader("Pragma", "no-cache");
      res.setHeader("Expires", "0");
    }
    next();
  });
}

const plugins: IPlugin[] = [httpPlugin];
const app = new App({
  logger: new ConsoleLogger("tab", { level: "debug" }),
  plugins: plugins,
});

app.tab("home", path.join(__dirname, "./client"));

(async () => {
  await app.start(+(process.env.PORT || 3978));
})();

Key Points

Environment-based control: The middleware is only added when the RUNNING_ON_AZURE environment variable is not set (i.e., during local development)
Path matching: Paths ending in .html, the root path, and paths without extensions (SPA routing) are treated as HTML requests
Cache-busting headers: Three headers — Cache-Control, Pragma, and Expires — are set to ensure caching is fully disabled

Benefits of This Approach

Hashed filenames are preserved: JS/CSS files keep their hashes, so production environments' caching efficiency is unaffected
No impact on production environments: Since it's controlled by an environment variable, the middleware is not added during Azure deployments
Extensible: The same technique can be used to add logging, authentication, custom headers, and more

Use Case: Adding Other Middleware

Using this technique, you can add various middleware to the Teams SDK.

// Add request logging
httpPlugin.use((req, res, next) => {
  console.log(`${req.method} ${req.path}`);
  next();
});

// Add custom headers
httpPlugin.use((req, res, next) => {
  res.setHeader("X-Custom-Header", "my-value");
  next();
});

// Add authentication for specific paths
httpPlugin.use("/api/private", (req, res, next) => {
  if (!req.headers.authorization) {
    res.status(401).send("Unauthorized");
    return;
  }
  next();
});

Caveats

This approach relies on the internal implementation details of Teams SDK v2 (@microsoft/teams.apps v2.x)
The API may change in future versions
This usage is not documented in the official documentation

Conclusion

We discovered that Teams SDK v2's HttpPlugin uses Express internally and exposes the use() method. By taking advantage of this:

HTML caching issues during local development are resolved
Cache-busting via hashed filenames is preserved
Development experience is improved without affecting production environments

We hope this helps anyone working with Teams SDK v2 who runs into the same issue.

This article was originally published in Japanese at archelon-inc.hatenablog.com.

How to Change the Emoji Font to Noto Color Emoji in VS Code on macOS

upa_rupa — Tue, 31 Mar 2026 10:26:33 +0000

Introduction

Have you ever wanted to change the look of emojis displayed in VS Code?

On macOS, Apple Color Emoji is used by default for emoji rendering. While Apple's emoji designs are polished, some people prefer Google's Noto Color Emoji.

However, many online sources claim that "Noto Color Emoji doesn't work in VS Code on macOS."

In this article, we'll show you how to use Noto Color Emoji in VS Code on macOS, based on steps we tested and verified on macOS (Apple Silicon).

TL;DR

It's surprisingly simple — just two steps:

Install the Noto Color Emoji font
Update the font settings in VS Code's settings.json

No Custom CSS extensions or system-level font configuration changes are needed.

Steps

1. Install Noto Color Emoji

Install it using Homebrew:

brew install font-noto-color-emoji

2. Update VS Code Font Settings

Open settings.json and configure as follows:

Editor:

"editor.fontFamily": "Your Font Name, monospace, Noto Color Emoji"

Terminal:

"terminal.integrated.fontFamily": "Your Font Name, monospace, Noto Color Emoji"

Restart VS Code after making these changes.

Key Point: Don't Use Single Quotes

Normally, font names containing spaces are often wrapped in single quotes (e.g., 'Noto Color Emoji'). However, in our testing, it worked correctly without single quotes.

When quotes are added, macOS's system font fallback may prioritize Apple Color Emoji. Omitting the quotes allows VS Code (which is Chromium-based) to correctly resolve and use Noto Color Emoji.

Approaches That Didn't Work

During testing, we also tried the following approaches, but they were ultimately unnecessary:

Overriding with Custom CSS Extension

You might consider using vscode_custom_css.imports to replace Apple Color Emoji with Noto Color Emoji via @font-face:

@font-face {
  font-family: 'Apple Color Emoji';
  src: local('Noto Color Emoji');
}

While this worked for the editor area, it doesn't affect the terminal because the terminal renders via Canvas/WebGL, which means CSS overrides are not applied. In the end, the editor.fontFamily setting alone was sufficient.

System-Level Font Changes on macOS

Modifying CoreText's fallback settings is another option, but it risks breaking with macOS updates and affects all applications, so we don't recommend it.

Why This Method Isn't Well Known

VS Code is an Electron (Chromium)-based application. Chromium's font fallback handling can behave differently from macOS native applications.

Many articles explain that "Apple Color Emoji is prioritized at the system level on macOS, so it can't be changed." This is generally true for native macOS applications. However, in Chromium-based apps like VS Code, font-family specifications are more directly reflected in font selection, which is why this method works.

Test Environment

macOS: Darwin arm64 25.1.0 (Apple Silicon)
VS Code: 1.109.4 (Universal)
Electron: 39.3.0
Chromium: 142.0.7444.265
Noto Color Emoji: Installed via Homebrew
Also verified working over Remote SSH connections

Conclusion

Changing the emoji font in VS Code on macOS turned out to be much easier than expected. Simply add Noto Color Emoji (without quotes) to editor.fontFamily and terminal.integrated.fontFamily.

Despite widespread claims online that "it's not possible on macOS," by taking advantage of the fact that VS Code is Chromium-based makes it achievable with a simple settings change.

If you'd like to change the look of your emojis, give it a try!

This article was originally published in Japanese at archelon-inc.hatenablog.com.

References:

DEV Community: upa_rupa

[iTerm2] Send Clipboard Images and Files to and from SSH Hosts with a Single Keystroke

The Problem

Tools Exist for Images, but Not Quite What I Wanted

What I Ended Up With

⌘⇧V: From the Mac to the SSH Host

⌘⇧D: From the SSH Host to the Mac

Folders and Large Files

Making It My Own as I Go

How to Use It

1. Assign the Keys

2. Let SSH Connect Without Asking for a Password

3. Raise the Selection Size Limit

Caveat: How Far It Reaches

Wrapping Up

VS Code Remote SSH: Automatically Invoke VS Code as Your Editor from External Terminals

The Problem to Solve

Background: Why code Doesn't Work from Terminals Outside VS Code

The Solution: A Wrapper Script Called editor

Creating the Script

Granting Execute Permission

Shell Configuration

How It Works

Auto-discovering the Latest Socket

Use from External Terminals

Handling No-Argument Invocation

Where This Helps

Behavior Summary

Closing Thoughts

The Nine-Year Journey to the Orca Emoji (U+1FACD) — How a Single Character Moved the World

Basic Info

2016–2017: Voices Rise Around the World

February 2019: A Third Person Steps Up

Search Popularity Comparison

No Existing Emoji Covers It

Sample Images

2019–2023: The Gate Is Closed

The Iron Rule: Once Added, Never Removed

A Strategic Pause — Shifting to Quality Over Quantity

Marcos's Proposal, Waiting at the Gate

2024: The Gate Reopens

September 9, 2025: Official Adoption

The Emoji Approval Process: Open, but Careful

Platform Support Status (as of March 2026)

Display Test with Noto Color Emoji

Summary

References

Auto-Configure Git Hooks for Your Entire Team with Just npm install

No more "Git hooks weren't working on my machine"

Local Git hooks and GitHub Actions: Better Together

The Setup: core.hooksPath + npm prepare

1. Create a hooks directory in your project

2. Write your hook scripts

3. Add a prepare script to package.json

Why This Works

Simpler Onboarding for New Team Members

Monorepo Support

A Real-World pre-push Hook

Summary

How to Match Only `/` in CloudFront Using `/?*`

Introduction

The Constraint: CloudFront Path Patterns

How the Pattern Works

Breaking Down the Pattern

💡 The Mechanism

Matching Results

Fine-Grained Routing: SSR vs. Static Assets

CDK Implementation Example

Strategic Advantages

⚠️ A Subtle but Crucial Limitation

Summary

The "Reply to Author" Pitfall in Google Groups — Why Your Messages Seem to Disappear

Introduction

What Actually Happens

Why Does This Happen?

Watch Out for Delivery Settings

A Known Issue for Users Worldwide

How to Avoid This

The Reliable Fix: Reply via Gmail

Other Workarounds

Background: Why `code` Doesn't Work from Terminals Outside VS Code

The Solution: A Wrapper Script Called `editor`